Show HN: Radi, my HTML5 content creation app (Mac)
radiapp.com
radiapp.com
It's scary to put this app out there to the whole world in its current condition, but I feel like I've reached a dead-end.
There are too many directions in which this app could be developed. I need to cut down on the abstract ambition and start focusing on some real-world use cases.
For that, I desperately need your help! What's your biggest need in the world of HTML5 content creation? Do you see a path for this app to be developed into the tool that would fit your needs?
Thanks for any input, and (slightly prematurely) a great 2011 for everyone on HN! I appreciate this community enormously.
--
A few words about the technical details of this app...
Although the app targets HTML publishing, the compositing core doesn't actually use any kind of browser engine like WebKit. Instead, it's a node-based GPU-accelerated compositing system of my own devising. Layers and effects are rendered using OpenGL.
Because there's no browser engine, there's also no browser-style DOM available in Radi. I've written private implementations of the relevant JavaScript APIs, primarily Canvas. The JavaScript engine used is WebKit's JavaScriptCore, a.k.a. Nitro in its current accelerated incarnation.
The app is native Cocoa, but it's written in a way that's fairly portable. (From my other projects I already have a large part of the core ported to Windows+Direct3D.)
Clearly you've solved a lot of interesting technical problems, but I feel kinda clueless while using it. As far as I know the only people who use the flash authoring environment these days are advertisers and animators (or designers building content for flex apps). So if you want to focus this, I'd say go after those people. When people do make flash sites in the authoring environment they usually rely heavily on simple onclick and gotoandplay statements.
I'm impressed with what I see, but I don't know what problem has been solved.
That's why I felt like I need to release this sooner rather than later. It would be appealing to go on polishing the app for an imaginary customer who happens to be just like me (my other application, Conduit Live, went down that drain)... But it's healthier to face criticism and try to figure out if there's some potential customer group(s) out there that I didn't anticipate.
FWIW, I feel like there might be something interesting to be done in the intersection between realtime graphics and video on the web. Flash has a lot of cool technology, but nowadays you need to be a coder to take advantage of the new stuff like Pixel Bender shaders or the Alchemy compiler -- Adobe seems to have "outgrown" the designer audience who originally made Flash a success, and I think that's a mistake.
Re: your points about Radi -- there's a big hole in the <canvas> publishing functionality currently, it doesn't export all keyframes. Sorry about that, I'm hoping to fix that ASAP. The keyframing UI is not very well thought out, and needs a lot more work. To make polygon shapes, choose "Draw Shape" from the toolbar and click away in the viewer. There's no exposed way to limit the shapes' visibility in the timeline either (internally there's a concept of empty keyframes same as in Flash, but it's not in the UI).
I can't imagine the repercussions of cutting down the program down the line after people have acquainted themselves with it - to the point of feeling completely entitled.
I remember when we had to design a service and an interface for it in Flash in college. The university did not provide an Adobe license, so the license would run out right around the examinations, assuming you hadn't installed it earlier to play around with. They basically wink-wink-nudge-nudged people into pirating the whole thing.
Had we had something like this, things would have been so much easier in every conceivable way. Working with Adobe Flash was perhaps the worst experience of my time in college.
It's funny to think about sites like newgrounds.com and kongregate.com and how HTML5 might challenge the domination of Flash.
You may have a good reason, I just can't think of it off the top of my head.
But I do think there is a solid case for this approach. Consider something like image filters and applying them to video. If the authoring UI were implemented in WebKit, I don't know how I could get realtime responsiveness for video manipulation. Now it's no problem in Radi because the rendering bottleneck to produce actual browser-playable <video> content only happens upon publishing.
Being on the native side gives me a theoretical edge when it comes to new browser features -- I'm thinking of something like visual effects which may be supported only by Mozilla but not WebKit, or vice versa. Not being married with a specific engine could be an advantage.
It's worth mentioning that Radi does actually use WebKit to render the content in HTML layers. So you can place custom HTML within a document, and it's rendered with browser-style text antialiasing within the app. (It's not dynamic, though -- just a snapshot of the HTML rendering.)
http://i.imgur.com/6BC1o.png Recoil/long-neck guy, a meme. Pardon the banality, but it's what I actually did when I was reading this.
You are one ridiculously industrious individual. Congrats, I can't wait to find an excuse to tinker with Radi. :)
Anyway, I had fun playing with it. The timeline gives me happy/terrifying Director/Flash flashbacks. I can't figure out how to make an animation cycle in the timeline (i.e. like a walk animation) without cheating & creating keyframes by moving stuff to a slightly different (x,y).
I also couldn't figure out how to script top-level elements (does everything need to be composited inside a cavas?). I added a number of "picture layer" objects that I wanted to move via keyboard control. I couldn't figure out how to put a script in the topmost layer to do this (nor could I see how to reference the sub-layers so that I could move them). I might have been fooling myself -- it looks so much like Flash or Director, that I expected to be able to write a top-level script that controls all of the sub-elements. If that's not possible due to the overall layer architecture, you should make that clear (by making the other scripting opportunities explicit when available).
A few quick suggestions:
- The "command line" input in the script editor is a great idea, like the "message window" of HyperCard or FaceSpan. I think you'd do well to make it its own window, and have the last result displayed underneath the input area (ala FaceSpan) so I don't have to wrap everything in sys.trace.
- Positioning elements via arrow keystrokes doesn't seem to work -- please implement bindings similar to Interface Builder (or FaceSpan) where modifier do useful things like snap to grid and stretch.
- JavaScript API reference menu item doesn't seem to work. I found it eventually (http://lacquer.fi/developer/conduit-js/#sys in case anyone else has the same problem).
Overall, it looks great. I can't wait to hard to believe you kept it quiet long enough to do all of this. Congratulations!
I know what you mean by the happy/terrifying timeline :) I thought hard whether it would be misleading to make the timeline look so similar, especially when it doesn't have the same functionality at this point, and the quirkiness of Flash keyframing has been such a source of frustration to users. But I decided that the big elements need to have a certain familiarity in order to make the app's purpose more obvious at a glance. (I guess it would be the same if I was making a photo editor: there are some UI conventions that are clearly outdated but people expect them from years of Photoshopping.)
There is a document-level scripting environment, but it's not exposed to layers yet -- the JavaScript hooks to the compositing system don't exist yet, and the UI to tie it together with the timeline has not been designed. The way Flash implemented this is clearly pretty nasty, so I'd like to come up with something a bit cleaner, hopefully.
Re: the script editor command line -- it does print out eval results without wrapping them in sys.trace (so if you type "2+3" or "Object.keys(sys)", you get the expected printout -- unless of course I've broken that at some point without noticing). But clearly that UI leaves a lot to be desired. I'd like to do something about those floating panels anyway, so maybe I'll get to redesign the script editor at that point.
Do you take it? ... Or do you create a new software empire for the creative web development world to rival Adobe but built on open standards?
I noticed this: "Radi makes creating vector graphics easier with its unique autosmoothed shapes. When you apply smoothing to a corner point, all your control points lie precisely on the shape's outline. There are no separate "handles" or "tangent points" to be tweaked outside of the actual shape."
Just wanted to point out that, to me, that sounds like an anti-feature. Maybe it's a nice alternative tool for quick, smooth shapes, but I've watched many an illustrator tweak the hell out of those things to get exactly the right curves and sharp angels. I also remember reading a story about how Microsoft spent weeks observing video of expert Adobe suite users with various Pen-tools to get the feel of the handles juuust right for an easy transition to Expression suite products.
This is a cool side project and letting HN hammer on it is a great start, but you're going to need some artists to hammer on it before you've got something really special.
Right. I know that illustrators love their Bézier handles, but I'm not 100% convinced that everybody else loves them all that much. I used to do graphics for a living, and I never felt very comfortable with Béziers (although that was also because my style was pretty much opposite to sharp vector designs).
The Radi curve engine does support Béziers, but implementing the UI for managing the control points seemed like a complete drag (what a terrible pun).
So I figured that maybe I should try doing what Apple does so well: market the "anti-feature" as something new and unique. No handles -> less UI complexity -> ??? -> profit!
I was also inspired by 3D modelling applications, where a lot of work is done with subdivision surfaces which are controlled by automatic control points, essentially similar to the curves in Radi. I know there was an older generation of modelling apps with free-floating handles, and I get the impression that modellers are happy to be rid of those (but maybe I'm wrong about this one).
In my opinion I think you should reorder your site so that the first headline and blurb explain that Radi is a Mac Application for producting HTML5 compatible vector animations. The stuff about HTML5 can probably be below the fold.
Currently, we are solving this problem with a mish-mash of Ruby/Sinatra and jQuery/Raphaël but its not clean or easy. Would this be something that Radi could help us build and maintain?
I've done a fair amount of work with dataflow UIs in the past, and it sounds like this could be an opportunity to leverage that work. To illustrate, here's a sample screenshot from my other product, Conduit Live (a video compositing app):
http://lacquer.fi/images/cl2_screenshot_drowned_3.jpg
I'd especially love to see this ported to Linux. Also, is there a place where we can donate? I don't exactly have $200 to throw down on your other piece of software, and I don't own any iOS devices for your $1 app.
Thank you all so much for the encouraging comments!