I am developing a "timeline editor" application (picture something like Audacity or iMovie) that lets a user create and arrange clips on a timeline and play them back.

The user can zoom in and out to change the horizontal resolution of the timeline to be more or less detailed, and can click within the timeline to move the playhead to a specific time.

The user can save their timeline to disk, and reopen a previously saved file. Like many applications, a warning is shown if the user attempts to close the file with unsaved changes.

My question is, should the current playhead location and current zoom level be part of the save-file?

Pro: If I save and close the file and reopen it later, then my view is restored exactly how it was when I closed it.

Con: If my only change since my last save was to move the playhead or change the zoom level, then it seems strange to be warned that I have unsaved changes when I close the file.

What do other applications do? Are there standard conventions around this? Will users expect a certain behavior here?

1 Answer 1


As the designer of above mentioned timeline editor application (Audacity) - there's a distinction to be made between application state (gets saved automatically/to your preferences) and project state (gets saved with the project). It's tricky to decide whether view (or even - which part of a view) belongs to which.

For audio editors, I'd want to make a distinction between view stuff that happens in the project area (track height, timeline settings, waveform vs spectrogram, etc) and view stuff that happens elsewhere (language, toolbar configuration, workspaces, etc). I'll get into the why a bit further down.

Con: If my only change since my last save was to move the playhead or change the zoom level, then it seems strange to be warned that I have unsaved changes when I close the file.

The same thing is true for your undo stack: you don't want every selection change and zoom event to be its own item in the undo stack as that'd make it pretty cumbersome to actually undo anything.

As for the undo stack, you can roll view events into project events, so for example "Import -> zoom in -> trim -> scroll view" would have the zoom and scroll steps rolled into the project events and undoing would set your project and view into a previous state. This behavior makes sense for view events which directly affect stuff within the project area/viewport, toolbar layouts not so much. Audacity does this "rolling multiple changes into one event" all over the place, perhaps even too much in some cases.

You can do something similar for saves - changing the view alone wouldn't need to prompt a "do you want to save?", but the view could be saved together with actual project changes.

What do other applications do?

As an example for another app, Blender is of the opinion that everything view-related belongs to the project, so all your workspaces, current viewport rotations and such are stored in the project. This does have the advantage that I can return right where I left off, but when I send that project to someone else, they will see what I last worked on - and given the customizability of blender's interface, they might be completely lost as to where the menu/button/sidebar/view went they're used to seeing in their setup. Even opening my own old projects, I tend to get somewhat irritated because the layout is different to my default layout these days.

Are there standard conventions around this? Will users expect a certain behavior here?

As for conventions and expectation, this depends on your target audience. If you're targeting users of one specific DAW or editor, it probably makes sense to take on some of their terminology and conventions where they make sense. You don't really get brownie points just because you found a unique solution to a problem that's solved well everywhere else.

That said: If your target audience is explicitly not industry veterans, there's very little point in emulating anything existing. Audacity for example is still using the tape recorder model quite extensively, hence why options about playing and recording are called "transport". Or why there is a workflow where, in a stopped state, you hit pause first, then record, set your levels, and then unpause to record something.

So when I look for conventions to follow, I don't actually look in other DAWs first and foremost, but in programs our audience actually is familiar with - browsers, smartphone apps, text editors, etc. And it's especially when looking at Google Docs, Microsoft 365 and Figma, I realize:

Maybe "just" automagically autosaving everything is becoming the new expectation, and warning on close is becoming pretty old-fashioned. (I don't think our field of audio/video editors is quite there yet, but I expect we'll get there this decade.)

  • My app has nothing to do with audio/music, I just mentioned Audacity as a reference for what I meant by “timeline editor”…but I’m glad I namechecked it if that is what garnered your insightful comments! I’m leaning toward what you said about midway through your post: save playhead changes/zooms with the file upon saves, but don’t consider them as save-breaking changes on their own. Good food for thought about “undo”; I’ll need to consider further whether Edit 1 > Zoom > Edit 2 > Undo 2 > Undo 1 should undo the zoom or not. I think likely not in my case but it’s an interesting question. Nov 16, 2023 at 23:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.