the list is getting too long

[typemytype]

a simple way to sub divide the list into smaller parts:

• tags
• developers
• installed with .mechanic
• per json stream

ui maybe similar to (columns on top with) :

the hard work is already done: inserting search queries to narrow it down

[gferreira]

see also: Scope Buttons

[typemytype]

adding some sort of user defined rating system (favourites), users could only subscribe to updates from those extensions

the goals is the lower the calls to any git repo and make Mechanic fast enough while the extension list is growing...

[gferreira]

here’s a UI sketch exploring the “iTunes” model:

see controller.py for the source (split view UI only, groups and filters not working yet)

• create new “extension groups” using the + button
• add extensions to a group by dragging them from the list and dropping into the group
• select a group to show only extensions in this group in the list (optional – if no group is selected, all extensions are shown)
• select one or more filters (tags, developers, sources) to further reduce the list

[jackjennings]

Of these, the tags seems most useful — if you want to filter by developer I’d assume that someone would search for their name (though I don’t remember if search looks at that field at all). Groups seem helpful but are there enough extensions to warrant this? Are there groups that would be useful beyond what already exist in tags?

[jackjennings]

Would a less visually complex option to have a filtering system like Finder's search mode? Or just a dropdown button to select a tag to filter by?

[typemytype]

this is already possible with the search bar on top...

the issue is that Mechanic grows and its getting slower as it has to make a connection to GitHub to receive data for each extension. Somehow it would be nice designers could make their own sub list of important extension, that they wish to receive updates from. Not everyone needs a check for update for the Goldener Extension... the list could also have ❤️, like favourites.

Making the tags more visible is a good thing...

[gferreira]

thanks for the feedback @jackjennings @typemytype

search is already very powerful, but it requires the user to type a search string every time he/she wants to use it (tags and developers are supported by search). I think having a visible list of tags and developers to click-choose from (not necessarily with this design) would make the filtering process more efficient.

continuing with the iTunes analogy, user-made groups correspond to playlists: a hand-picked selection of all extensions/songs available in the full combined stream. as a user I rarely want to browse the full list of extensions – there are many which I’m not particularly interested in. but there’s a group of favourite extensions which I use the most. there are groups of extensions needed for particular projects. there are extensions developed by myself (public, private and personal). there are extensions which I know have bugs. etc… having the ability to create custom groups would make it a lot easier for users to look at small sets of extensions separately. and most importantly: when checking for updates, Mechanic would only need to send out http requests for the few extensions in the selected group.

---

the interface is only half of the problem though. I’m wondering if we can’t get rid of http calls altogether when opening Mechanic. I know that images are already cached once they are loaded; so it takes some initial time to load data from all extensions, but after that everything works smoothly. what if we saved a copy of the fetched images and info attributes locally? so they could be used to build the list when opening Mechanic. we would only need to talk to repository to update the metadata, and to install/uninstall/upgrade.

[verbosus]

I only just noticed this discussion. The work I’ve been doing in #18 addresses some of the points raised here. Like Gustavo was saying in his previous post, my PR now caches the icons offline, and since every HTTP call happens in the background, the UI is a lot more responsive overall. Updating extensions doesn’t feel as slow as Frederik was mentioning anymore.

Which means we can start thinking about the UI again. In general, I think I would like us to move away from modal progress windows. A user can click “check for updates” and have some sort of progress indicator within each row in the table view, which clears asyncronously when the extension is updated, possibly with an overall progress indicator. But making it non-modal means the user doesn’t have their UI locked: they can still use Mechanic in the meantime, scroll, view stuff, etc.

It’s great that we have the search feature working, but we should think about how to make the predefined magic keywords ?update? ?installed? ?not_installed? discoverable. I kind of think there should be convenience buttons for these, or at least sorting options on the table (imagine if it had column headers, for instance.)

In general I think we could do a better job at showing what an extension does before one goes about installing it. Right now that job is largely fulfilled by the README.md on the extension’s github page, which—critically—is the only place that includes a screenshot of how the extension actually functions. We do sorta… kinda… support showing that: double clicking on an extension row brings up the Web page in the browser, but we could think about folding that into Mechanic.

Lastly, here’s something I know is silly, but I really want: I think installing extensions should be fun. Right now we don’t do much other than turn on a grey dot beside the extension name. We don’t have to go full confetti on this, obviously that would be annoying, but surely something more rewarding for the user could be done.

Anyhow, this is all moot until I complete the work of detaching the UI from the main Mechanic engine. My PR was all about making things faster, for sure, but it didn’t make the code easier to read, far from it. I hope to be able to address that soon, so we can prototype UIs without the additional burden of the async code I had to add.