3 ms·
Right, and both of those involve UX tradeoffs. Which was my point and why I gave them both as options in my initial comment. Having read the first half of the a
by vietor 16y ago
Right, and both of those involve UX tradeoffs. Which was my point and why I gave them both as options in my initial comment. Having read the first half of the article, I was expecting the second half to address the issues which these various options raise.
Sure you can "Just save state all the time", but doing so involves tradeoffs. Tradeoffs which were not addressed at all in the article.
Your MS Word example is exactly what OpenOffice does when it's been closed without saving. It's really obnoxious. I was hoping to read some UX insight into how to make those kinds of actions less obnoxious without losing their helpful functionality when it's needed.
In general I agree with the core idea of the article. But it lacked useful discussion about the hard UX problems involved, opting instead for some easy in-application examples.
- jasonlotito 16y ago> I was hoping to read some UX insight into how to make those kinds of actions less obnoxious without losing their helpful functionality when it's needed. An initial ideas I had, fairly trivial in the context of OpenOffice and Word asking to return to your previous state: If a short period of time has elapsed since closing the application, simply resume state. Short period of time would have to be determine, of course. But it's fair to say that if I close an application and open it again within a minute, I probably want to resume the state. Additional conditions could be added based on testing: didn't save in the last close might be a good indicator.