Eternity 2.2.3 has been released. It’s not a major release, since it doesn’t contain any new features. So why this blog entry? Because with this update I’m trying to address one of the bigger missteps I made designing and developing Eternity – times auto-adjusting. As a small offering, I’ve also added more sounds to choose from in Pomodoro alerts and a bunch of bugfixes.
Here is some history, if you like to read how to screw up something. If not, click here to go straight to the new design description.
My initial solution to this was adding a switch and some context to the times editing screen:
When the switch was ON, every time you edited start or stop time of the central entry, the adjacent entries’ times would be “pushed” not to overlap the new times. But when you edited it back, the adjacent times would NOT be pulled back. It was meant to make it easy to do both: adjust times and create gaps.
But it was seen as inconsistent by many users: “When I edit start time to earlier, the previous entry auto-adjusts, but when I correct it back, it doesn’t – what the frig?”.
So, in update 2.2.1, I decided to add a “small” improvement. If the switch is ON, every time you edit start or stop, the adjacent times will auto-adjust, even if they had no contact before or after the time change. It’s logical, isn’t it. The switch label says “Adjust prev. & next” right? And it’s ON right? Well, not so much. And for many reasons. To name just a few:
- Users got used to how it worked, even if it wasn’t optimal and I changed this behavior without any way for them to know that (except emailing me). A big no no.
- It wasn’t obvious how the switch affected how time editing worked. The label said something, but switch’s visual relationship with other GUI elements didn’t give many useful clues.
- And this is best: many users didn’t notice the switch on this screen at all! It wasn’t their fault. When we have a goal oriented scenario (like “make this start 5 min earlier”), we have a tunnel vision – we skim through the GUI elements, choose the ones that seem related to what we want to achieve and use them. Switch is a setting control – it enables or disables something – there was no obvious place for it in a “move this time 5 min earlier” scenario. And it had a somewhat cryptic name. And it was somewhere below. Maybe if it was on top… But I doubt it.
This caused many headaches to my customers and I apologize for that. I corrected it a little bit with update 2.2.2 to make the auto-adjusting take effect only if there was an overlap before or after the time change, but it was just a temporary solution. I came to the conclusion that the switch-based design is just wrong and decided to re-design this view to…
We have three log entries here and two buttons between them – close to their times – which, I hope, makes their relation to the times obvious (and easy to reach with your thumb, if you’re right-handed). The buttons’ icons change depending on context.
- The arrow – eliminates a gap or overlap. It changes the selected time to the one it points to. And if you tap it, see the next point…
- The link – indicates the times are same and will be moved together. You can un-link them by tapping on the button and if you separate the times the button will change to arrow – see the previous point…
Overlaps are orange and errors are red (like stop preceding start or entry starting in the future). Entries can end in the future – something some users wanted. If you move linked times, the also-moved time will be highlighted briefly – to notify you when you’re focused on the time wheels operation.
I hope it’s an improvement over the previous version, however please keep in mind that the table-based time editing is only for simple adjustments or if you want to move an entry by a big interval (like one day, or week). For more complicated time arrangements, there is nothing like a full graphics and touch-based editing provided by TouchLog mode, which you can read more about here.