I said in an earlier post that a splash screen is an admission of failure. But, failure to do what?
Failure to write an application that can start up in a reasonable amount of time, is what.
It's good that you're showing the user something to reassure them that their double-clicking on the application icon actually did something. It's not so good that the bigger problem hasn't been addressed: they still have to wait around for the real application to show up, and worse they have to stare at an advertisement for the very program that's annoying them while they wait. Branding, schmanding. While I suppose you do create a branding impression that way, it's more along the lines of a Pavlovian association: oh, it's that software that takes forever to start up -- I wonder if I have any new email?
Do whatever you have to do to get the user into the application as soon as possible.
One of the contributing factors to long startup time in earlier versions of Inkscape was the fact that we pre-rendered all the icon bitmaps when the application first started, since it caused too much UI lag to render them all on-demand. This process took a while, and of course someone suggested that we add a splash screen. I proposed instead that we show the interface right away and render the icons in an idle task, which Jon Cruz then implemented to good effect: by the time the user got into the dialogs and menus, the bulk of the icons were pre-rendered. Recent versions seem to be taking a while to start up again, so perhaps it's time to look at what else we might need to optimize.
Even if you can't have a functional UI right away, it's still better to cheat a bit and show the shell as quickly as possible -- IE4 used that trick, showing the UI shell right away, but deferring any user input until initialization finished. Most users never noticed, and thought it started up faster than it really did. It's best not to resort to that kind of trickery if you don't have to, but I still think it's better than making the user sit through your pre-movie advertisement.
[Incidentally, if you're trying to use Inkscape on OS X and are having problems with an inhumanly (minutes/hours) long initial startup time, that's a problem in fontconfig specific to OS X that we haven't found a way to work around in Inkscape yet. Unfortunately, it doesn't happen to everyone, so our OS X developers are a bit stymied. I'd still rather someone spent the time to track down and fix the fontconfig issue rather write a cute splash screen for Inkscape.]
2 comments:
You said before that you didn't like inbetweening, or at least the way it was done in the tools that you've seen.
I wanted to see if I could imagen the kind of inbetweening tool I would like to use in order to animate complex svg images. I figured one of the first things I'd want is ghosting of previous keyframes (and maybe some quick access options to change how it's combined (think stop motion camera)) I'd also want to be able to drag nodes through the 4th dimension by having them selected as I move through time effectively freezing their position while other none selected nodes continue to animate, with a new keyframe where you want the transition to continue from (think stretching over time).
I reckon some kind of filter where you can import from inkscape say each keyframe and have the node id's linked up so inbetweening can take place, and make it a rule that all transitions are smooth (none of this suddenly disappear or move at the next keyframe stuff because that doesn't make sense) it'd also be nice to export or change a inbetweened frame by turning it into a keyframe and doing your mods to fix any errors.
Email me if you'd like me to continue, or perhaps just email me a polite note tat you think my ideas are nice but rubbish (which they could well be) but I thought better get ideas written down and laughed at than lost.
Since you didn't provide your email (your blogger profile isn't published, either), I'll reply here...
I don't have anything against tweening per se, but implementing shape tweening well has proven to be a hard-to-solve problem: i.e. if you give a piece of software a "before" shape and an "after" shape, it's pretty hard to compute intermediate shapes which are pleasing, even with a lot of user assistance. Generally, Moing will not let you manipulate individual nodes; any shape-changing is accomplished using pegs to control the distortion of the overall shape.
Other kinds of tweening -- position tweening, for example -- are pretty much the bread and butter of Moing, though in many cases keyframes will be implicit rather than implicit. It seems like sometimes discontinuities ("jumps") are going to be necessary to allow, but maybe not -- we'll see how things actually work out.
I agree that "ghosting" ("onion skinning") is a useful feature. I will think more about how it should work in Moing.
The way "4d dragging" will work is that the current frame changes with the mouse as you drag stuff in time on the timeline; the general effect of "live preview" should be similar to what you're describing.
Post a Comment