Open prkos opened 7 months ago
Thank you very much for opening up this issue! I am currently a bit overwhelmed by the many requests that arrive each week, so please forgive me, if I fail to respond personally. I am still very likely to at least skim read your request and I'll probably try to fix all (real) bugs if possible and I will likely review every single PR being made (please, give me a heads up if you intent to do so) and I will try to work on popular requests (please upvote via thumbs up on the original issue) whenever possible, but trying to respond to every single issue over the last years has been kind of draining and I need to adjust my approach for this project to remain fun for me and to make any progress with actually coding new stuff. Thanks for your understanding!
Thank you for your very detailed request. I assume labelling this as a bug was not intentional. Or am I missing something?
The funny thing about your request is, that I think you are missing something, yet you are automatically emphasizing that something could be improved. To me it seems you are not aware that you CAN actually type in your estimates and the current time spent. You just have to click into the 'click to edit' field:
With mobile devices in mind, the modal windows are intentional as far as I am concerned. With the exception of 'Description', each menu item opens a modal dialogue. What would you do to these?
Note: a lot of different discussions at first, the core of the Issue is last.
Bug or not: I'm not bothered by how you label it. I would argue that bugs aren't just code related, if that's what you were aiming at. A bug is anything wrong that needs to be fixed. UI is a part of the app, something wrong with it is a bug, until you create a label that is dedicated to UI "wrongs" (needing-UI-spec is different!). We can discuss and philosophize elsewhere if you want, it doesn't matter so much here in this Issue.
"Click to edit": :open_mouth: I either did miss it completely, or I did notice when I first tested superProductivity but forgot because I got overwhelmed and I loved the circle widget so much that I remembered it and the type-in field could be ignored.
I do think that this shows that there is something wrong with the "click to edit" approach. A good guideline when building interfaces is "Show, don't tell". I can try to guess what kind of a design would make it more obvious.
The default visual design for a field (in this app) seems to be a line at the bottom with a label or an icon to the left. So instead of a floating text "click to edit" you could just have a line at the bottom of that space. Clicking on the label "Time Spent" would focus it like it already does now. I don't think that having the label on the top instead of to the left would be confusing since it's a compact space inside the circle, the line would still be associated with the label in users' minds.
It is confusing to have that text "click to edit" spelled out with input fields being so familiar, and the dot on the circle isn't described anywhere while it's a custom widget (it took me some time to realize that you get permanent dots that show the registered hours, and initially it took some time to realize the clock face parallel).
If you feel, reading this, that I must be one of those users who aren't the brightest of the bunch :zany_face: you'd be wrong! If I may say so myself :grin: I've been building web projects for over 15 years and I've learned heaps when it comes to user interaction and making things accessible. I recommend all programmers who build their own apps to learn what good and bad UIs are about. I don't mean learn how to build UIs, I mean just understanding the basic principles of how users think when faced with a new interface, it would make them avoid some pitfalls. And go user-test some app you're not familiar with, just for the experience, that, my friend, is when your eyes open wide! Anyway, this also for another thread discussion.
Mobile devices, modal windows: Can you share more about that -modal dialogues are good for mobiles? Is narrowing the window the same as what you see on a mobile device so i can test like that? Do you think that modal dialogues are better because they are centered on the screen and small enough so you don't have to scroll to see it fully on a phone? What would I do with these you ask? I would keep the modal dialogues for small screens and made them accordions on larger screens where there is enough space not to lose the context of the matter. That is all opinions though, only user testing can give you the correct answer!
The core of this Issue: We've touched a lot of topics here, and we can separate them into other Issues, but the core of this request is about "merging" the two modal dialogues into one.
Regardless of the "Time spent / Estimates" is a dialogue or an accordion, I think that the second dialogue "Add for Day" functionality should be merged into the "Time spent / Estimates" dialogue.
Here's the edited proposal, you can ignore the modal/accordion and just focus on how the functionality of adding time for another day is incorporated into the "Time spent/Estimates".
The date field is pre-filled with the today's date or even the word "today" to be consistent as it's used elsewhere in the app, and the focus is on the field to enter the time (for today).
In the mockup the field is next to its date, but you might want to keep that in the circle widget center if it's easier, and only display the time next to the date field? In that case the date field should be highlighted to show what date you're setting the time for.
I added the clock hour ticks, those might be shown on hover and focus?
If you think any of this is interesting and easy to implement I can create a mockup that shows only the new things you aim to implement, without my additional suggestions, so it's easier for you to track the changes.
Again, the core of this report is combining the time spent today and time spent on other days into one interface so you don't have a modal dialogue open on top of a modal dialogue over the base app interface. This is to avoid having to keep track too many layers/contexts in users' minds, and to make keep the information of the same quality together.
Why are dates that are in the past so special that they need a separate modal dialogue? Is adding past dates so rare? Even if it is you can still have it all working on the same level without confusing users who only use it for "today".
Thanks for your input! I will be on vacation for a bit, but will think about this once I am back.
To conclude the changes you are proposing:
Merge Modal Dialogues: Combine the current two separate modal dialogues (one for adding time spent today and another for adding time on different dates) into a single, unified interface. This would simplify the process and reduce user confusion caused by having to navigate multiple modal dialogues.
Label Change: Change the label from "Time" to "Duration" to provide clearer meaning and context.
Interface Enhancements:
Visual and Usability Improvements:
Modal vs. Accordion: Consider implementing the unified interface as an accordion item within the task options for better usability on larger screens, while retaining modal dialogues for mobile devices to ensure usability without requiring scrolling.
Am I missing something?
Just as a first feedback: I think that some of the changes you are proposing won't work well, when there is limited screen space (such as on mobile or when the app is smaller besides other windows). The highlighting thing could be confusing and even frustrating when there is not enough space for all entries at the same time. Same goes for the accordion. Many people are using the app in a small window (including myself). So we have to consider this.
Wow vacation does you good!
I think you covered everything except adding the "clock ticks" to the circular widget. Thank you!
I'll play with small screens and try to see if there are adjustments that would help keep relevant pieces visible.
This issue has not received any updates in 90 days. Please comment, if this still relevant!
Yes it's still relevant :rabbit:
Expected Behavior
Adding Time spent interface is confusing, mostly because of how the logic of the dates is handled. It should be clear from the interface what to click on when trying to add new time and currently it requires a lot of reading and thinking and sometimes making mistakes when not being careful (for example if I don't use superProductivity for a while and come back to it I know I can add new time spent for different days but I make a mistake if I'm not doing it slowly and intentionally), which is a sign of an interface that could be improved.
Current Behavior
Time option of a task opens a modal dialogue that allows for adding time spent for today if there are no previous entries, and adding the estimation time. When trying to add time for another date it opens another modal dialogue on top of the original one that allows for adding a date and time:
Proposal
One way of improving this interaction is to combine the two modal dialogues into one, I made a tentative mockup of what the new layout might look like, data shown isn't consistent, this mockup is only to show the possible new flow of interaction.
The current option label "Time" seems too vague, I'm proposing to change it to "Duration".
Estimates are only one time duration, and times spent can be many, and the categorization of those info is different so it makes sense to separate the Estimates into their own box (a different background color is sufficient) but I've also added a text (time) field for it so it can be filled in by typing and not only using a mouse on the circle widget.
Time spent has its own box on the mockup but it would probably be better without the background so the interface is less cluttered and the Estimates is contrasted more.
When the dialogue is opened the first combination of date-time fields is automatically highlighted and the date is set to the current date, the time field is in focus so you can immediately enter time by typing. The circular widget above can be used to enter the time with the mouse, it always affects the currently highlighted date-time and is updated as you highlight/focus different date-time rows.
As is already implemented the date fields can be filled in by typing or by clicking on the calendar icon to popup a calendar and use the mouse.
The time field is a new addition that allows you to type in the time duration. Currently that is only possible by using the circle widget. As I mentioned the widget should be linked to the currently focused field.
"Add another" button should add a new date-time row to appear in place of it and "push" the button downwards.
Cancel and Save buttons are associated with the entire form, Estimates included, possibly center-aligned horizontally.
The mockup is showing the entire dialogue as an accordion item in the task options, the accordion might be a better usability option for all of the task options, but this change can be implemented as a popup dialogue if it's quicker, it would still make adding previous dates much faster and easier if it's all on one plane with fewer context changes and needing to read labels to figure out the process.
If anyone is interested in working on changing the logic I can do the HTML/Sass/CSS. I've never used Angular but I've worked with other similar frameworks.