Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streamline adding new time durations #3141

Open
prkos opened this issue Apr 13, 2024 · 6 comments
Open

Streamline adding new time durations #3141

prkos opened this issue Apr 13, 2024 · 6 comments

Comments

@prkos
Copy link

prkos commented Apr 13, 2024

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:

currentTimeAddnewDate

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.

superProductivityNewDateProposal

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.

@prkos prkos added the bug label Apr 13, 2024
Copy link

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!

@Jagdfalke
Copy link
Collaborator

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:

image

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?

@prkos
Copy link
Author

prkos commented Apr 15, 2024

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": 😮
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 🤪 you'd be wrong! If I may say so myself 😁 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".

superProductivityNewDateProposal2a

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".

@johannesjo
Copy link
Owner

Thanks for your input! I will be on vacation for a bit, but will think about this once I am back.

@johannesjo
Copy link
Owner

johannesjo commented Jun 7, 2024

To conclude the changes you are proposing:

  1. 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.

  2. Label Change: Change the label from "Time" to "Duration" to provide clearer meaning and context.

  3. Interface Enhancements:

    • Separate Estimates Box: Create a distinct box for Estimates with a different background color for better visual differentiation. Add a text field to allow users to type in the estimation time instead of only using the circular widget.
    • Time Spent Box: Allow users to add multiple time entries without a separate background to reduce clutter. Highlight the first date-time field automatically and focus on the time field for immediate data entry.
    • Date-Time Fields: Allow users to fill in the date fields either by typing or using a calendar icon. Introduce a new time duration text field to allow typing in the time, linked to the circular widget for consistency.
    • "Add Another" Button: Enable adding new date-time rows dynamically when the button is clicked.
  4. Visual and Usability Improvements:

    • Click to Edit: Replace the "click to edit" text with a more intuitive design, such as a line at the bottom of the space with the label "Time Spent" to make it more recognizable as an input field.
    • Highlighting and Focus: Ensure the circular widget reflects the time for the currently highlighted date-time row and updates dynamically as different rows are selected.
    • Cancel and Save Buttons: Align these buttons with the entire form to apply changes cohesively.
  5. 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.

@prkos
Copy link
Author

prkos commented Jun 7, 2024

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.

johannesjo added a commit that referenced this issue Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants