Closed pmeinhardt closed 4 years ago
Looking at your screencast, I like the new approach. It's not radically different and seems to work good for the usual use case.
From a UI perspective, I think, it is still not 100% clear what the extension will do. It pops up three "tabs" and clicking on them doesn't visually do anything other than "selecting" a tab.
I know it is copying something to the clipboard, but this is nowhere to be seen in the UI.
Generally a nice idea ๐
Just quickly dumping some thoughts ๐ง
I know it is copying something to the clipboard, but this is nowhere to be seen in the UI.
Good point. Do you think it'd help if we - for instance - wait a moment before closing the popup after clicking a button and render a "Copied to clipboard" message @tessi?
- One problem I see is that we're missing a (at least to me) core feature: the summary button (which we still have to adapt -> will open an issue later) to get a title string which is fit for joblogs.
I was considering dropping the "summary". To me it seemed like a feature that people don't really use (which might also be easier to gather from other sources, e.g. via the command line on your machine).
Also, a lot of the issue trackers we support don't really have a way of selecting multiple tickets (I think GitHub is pretty much the only one).
Maybe we can collect some feedback on who actually uses the summary feature?
- From currently working on the notion.so support and seeing their huge ticket (page) IDs, I'm wondering how we can render a suitable dropdown for tickets with long names and still keep it usable ๐ค
My idea was to just show the ticket titles (without IDs etc.) in the dropdown. What do you think?
which might also be easier to gather from other sources, e.g. via the command line on your machine
I guess it depends on the project and position you're in. Let's say you spend your day in a workshop a pairing session on someone else's machine and on a investigation ticket. In this case it would be easiest to select all tickets on the board and copy their id and title via the summary button.
This said, the summary button is currently broken for this usecase anyways I think.
Still, I feel like once repaired, the combination of the summary button and selecting multiple tickets can be really powerful.
Oh and slightly off topic, but looking at your screencast I wondered if we could adapt for dark mode in macOS ๐ค. There's e.g. prefers-color-scheme ๐
I guess it depends on the project and position you're in. Let's say you spend your day in a workshop a pairing session on someone else's machine and on a investigation ticket. In this case it would be easiest to select all tickets on the board and copy their id and title via the summary button.
This said, the summary button is currently broken for this usecase anyways I think.
Still, I feel like once repaired, the combination of the summary button and selecting multiple tickets can be really powerful.
Maybe we do another hacknight ๐พ and think about the scenarios?
From a UI perspective, I think, it is still not 100% clear what the extension will do. It pops up three "tabs" and clicking on them doesn't visually do anything other than "selecting" a tab.
I know it is copying something to the clipboard, but this is nowhere to be seen in the UI.
This information is currently available via the info
link in the top row. I think this link could still be somewhere on the bottom of the popup without overloading it ๐คท
I tried to summarize the existing solution, your prototype and an alternative prototype I had in mind with an image:
After reading the discussion here, I thought that we should
Good point. Do you think it'd help if we - for instance - wait a moment before closing the popup after clicking a button and render a "Copied to clipboard" message @tessi?
What do you think?
Yes, a visual indication after pressing the button probably helps a lot. Probably Copied!
is enough.
@pmeinhardt i see you're churning out commits here, which design are you pursuing? Shouldn't we agree on an UI first? (just so you don't spend time building something which we decide to change later)
@pmeinhardt i see you're churning out commits here, which design are you pursuing? Shouldn't we agree on an UI first? (just so you don't spend time building something which we decide to change later)
Hey @tessi, I've just been doing some more work towards the parts that we all agreed on. I'm a bit slow because there was some on and off with a few other tasks, but I hope to have an iteration of this ready maybe tomorrow for another round of feedback. โ๏ธ
Here's an updated preview:
Let me know what you think. ๐
I like it much better than the previous version โค๏ธ thanks for your work here.
Is the summary button gone on purpose? And how does it look for only one ticket, does it still render the select box?
Hey @tessi, thanks a lot.
Is the summary button gone on purpose?
At the moment (with multi-line commit messages), the summary button doesn't quite work as expected.
Initially, I added it when Andi was asking for a helper to create job logs at the end of the day. However, I think the summary button isn't actually used much (at least based on feedback I received and personal use) and that it was never a really good solution for this problem. In a lot of tools, it's either not possible to find and select all the tickets you've worked on in a single day or at least it takes quite a few steps. Last but not least, the "summary" (with multi-line messages and pretty-printing) would introduce yet another, fourth, format for ticket information. It wasn't customizable and pretty much tailored to how we commonly do our job logs. This also limits its value for a tool that's used by (and aims to be used by) a number of people outside of bitcrowd.
@klappradla and I therefore came to the conclusion that we'd rather drop the button.
Please feel free to provide comments/thoughts if you think otherwise. โ๏ธ
And how does it look for only one ticket, does it still render the select box?
The current implementation simply disables the select element. The reasoning behind was that the extension popup keeps a consistent layout for the one ticket vs. multiple tickets cases. Additionally, it somewhat reassures you, that the correct ticket information was extracted. ๐ค
Again, if you feel like we should really hide it, please share your thoughts.
๐
Ah, I haven't seen the discussion to drop the summary button - but now that I see why, I agree. โ
About the drop-down: What about putting it before the button-row and making it:
About the drop-down: What about putting it before the button-row and making it:
* a heading if there is only one ticket (less distraction because it's not a UI element) * a select-box as it is now when there are multiple tickets detected
Personal preference, but I found the disabled dropdown I saw in @pmeinhardt's quick demo super neat and intuitive. It never looked like the wrong "fit" and never suggested interactivity where there was none. If possible, I'd suggest to use this in a internal test run of this PR first ๐ฅผ
๐ I agree that it's probably subjective to individual taste. so let's ship it as is before we get lost in detail here :)
This PR improves tickety-tick and is (from a design perspective) good to go if you ask me. Thanks @pmeinhardt for all the work and bringing it up and @klappradla for all the insight and opinions โค๏ธ
Thanks a lot for all the feedback and support. ๐
There's just a few open to-dos I hope to take care of maybe this evening or tomorrow.
I can also take over the remaining sub-tasks if you're busy @pmeinhardt ๐. Just ping me.
Yeah @klappradla, have a go. ๐๐ I am indeed caught up in project work today, so it'd be super cool if you can take this forward. ๐ฅณ
I completed your open TODOs to my best but limited knowledge @pmeinhardt and turned the PR from DRAFT into REAL ๐คน
I came across two tiny things we should at least take a look at. I'll probably turn them into separate issues and add a 4.0
milestone to make sure we tackle them:
1. Loading I find the loading indicator a bit weirdly placed in the new layout ๐
It may give users the impression that something is missing
2. Tabbing ๐ช
Having the select
tabbable when it is disabled may feel weird for users. At least in Firefox, one does not get a focus indicator on the field. Tabbing again will still continue on the buttons.
See these two scenarios for their visual difference:
โ๏ธ multiple tickets โ๏ธ
โ๏ธ single ticket โ๏ธ
I'd suggest to disable tabbing the "disabled" select. What do you think?
Just FYI: this is the 4.0 milestone -> https://github.com/bitcrowd/tickety-tick/milestone/9
Hey. ๐ I am looking for some conceptual (rather than code) feedback first.
It seemed to me like the usual case with Tickety-Tick, is that we're interested in just one ticket.
While in theory, the extension might yield multiple tickets for a page (if the user's in a list/board view or unexpectedly from multiple adapters matching for a page), we rarely have this case. 99% of the time, a user has exactly one ticket open or our adapters don't support the list pages.
I was therefore thinking about streamlining the popup design.
Instead of rendering a list where each item has the three copy-buttons, we only render one set of buttons. The select menu below is in case we get an ambiguous match (but is disabled if there's only one match).
Please let me know what you think. ๐