UI Redesign (1.0) about extension-manager HOT 10 OPEN

If you're willing, could you elaborate further on the extension page, e.g. what do the subpages look like? How would the review tiles work?

I'll expand on it in another comment later.

I think you can just adopt the design from the last GNOME Software mockups (although they still use old Adwaita look). You can find the full mockups on GNOME's gitlab issue. Here is a partial screenshot from it

I don't know if you can create this though since it needs various review data and there is no title for a review/comment on EGO. I created some simpler mockups based on the visible data on EGO in case the complex data isn't available:

(The Versions dialog is basically the 'download combobox' from EGO)

from extension-manager.

Thanks for this!

I think there's a lot to love with your design.

One of my sticking points with the current design is how browsing works. It feels disconnected from the installed extensions, a bit like it's two applications glued together (which to be fair, it is). The recently added detail page alleviates this somewhat, but not quite.

I'm a big fan of the combined search you've got. It makes far more sense in terms of unifying the two views. One concern I have is with how well it scales. If the user has a very large number of extensions installed locally, the online search results would get buried. I'm not sure how much of a problem this would be, especially with narrower rows like in your mockup, but worth thinking about.

You're right about the installed expander row being kind of pointless. One issue with merging this into the details page is that, at least presently, the details view requires internet access. We're unfortunately dealing with two completely different data structures, one for the local extension, and one for the web extension data. It's a technical limitation mainly - definitely do-able, but will need some thought.

Similar thing with the browse page having "featured" extensions. It's already a goal of mine, but it will need collaboration with upstream to add an API endpoint in extensions.gnome.org.

A major redesign of the GUI is off-the-cards for now, but I'd like to revisit this for version 1.0. Hopefully a lot more of the pieces will be in place by then.

In the short term, the detail view changes are the most do-able. I'd like to try implement that for 0.3 since I'm also aiming to have comments and reviews in. If you're willing, could you elaborate further on the extension page, e.g. what do the subpages look like? How would the review tiles work?

from extension-manager.

tl;dr: New extensions website is live (https://extensions-next.gnome.org)

There is a lot of cool stuff happening upstream and we should prepare for those changes.

The main thing appears to be featured Extensions (I assume from the Carousel on the main page). This is a good opportunity to do some UI Refresh work. Let's have:

1. Redesigned Browse Page with featured extensions, categories (?), and a search bar
2. A unified search view which will filter your installed and remote extensions
3. A slimmed down local view with just the essentials. Extension details move to the browse page which now will work offline.

Much of the groundwork for this is achieved in #517.

from extension-manager.

As of 0.4, we're fully adaptive for mobile.

I'm going to tackle this next for 1.0. Since this is basically a full UI rewrite, let's use blueprint files and libadwaita's new conditional layouts for everything. This means we'll be able to release after GNOME 44 at the earliest, depending on whether conditional layouts land in time, but it should make the app much more fluent to use.

I'd also like to figure out how to support connected animations in GTK for transitioning between views. Could be fun...

from extension-manager.

I'm a big fan of the combined search you've got. It makes far more sense in terms of unifying the two views.

My original idea was to just follow GNOME Software's design. That means putting the installed extensions among the online search results. But I saw the other issue about the search feature request on your repo. There you mentioned that you wanted to have a distinction between a search of installed extension and an online search. So I went with that approach for my mockup. It allows you to display the installed extension as fast as you can while loading the online search in the background for a 'snappier/speedier' search feeling. If you worry about data saving, then you could also hide the Downloadable section behind a button like this (depending on wether the search was initiated from the Installed or Browse page.)

One concern I have is with how well it scales. If the user has a very large number of extensions installed locally, the online search results would get buried. I'm not sure how much of a problem this would be, especially with narrower rows like in your mockup, but worth thinking about.

I personally think merging the installed extensions and online search results into one is better. It would address your concern and follow established design patterns from GNOME Software. But I don't know how many people use the search feature in the current GNOME Extensions app. Those would be negatively affected by this because the installed extensions would be buried among the online search (on page X) + the wait/load time... On the one hand the search feature was only requested (and added) last year and only by 1 person. On the other hand someone else already requested the local search for your own app. One solution to this could be a 'type ahead' feature when the user starts typing and hide the search behind Ctrl+F/the header bar button. Although 'type ahead' isn't GNOME-y at all...

One issue with merging this into the details page is that, at least presently, the details view requires internet access. We're unfortunately dealing with two completely different data structures, one for the local extension, and one for the web extension data.

at least presently, the details view requires internet access

Is your concern about data saving (i.e. mobile users) or wether there is just an internet connection at all? Even without internet access a subpage can IMO look good based on the metadata. Here an example with a placeholder icon/author.

Similar thing with the browse page having "featured" extensions. It's already a goal of mine, but it will need collaboration with upstream to add an API endpoint in extensions.gnome.org.

That would be ideal. My idea was just based around the current possibilties :)

If you're willing, could you elaborate further on the extension page, e.g. what do the subpages look like? How would the review tiles work?

Absolutely, would love to. I'll expand on it in another comment later.

from extension-manager.

Greetings!
It is possible that the design of the application icon does not match the Gnome theme. Of course, I do not insist, but still I ask you to consider the possibility of changing the design of the icon. Thanks!

from extension-manager.

@EvgenySurgut There's a new GNOME-style app icon as of #84 (and #99). This will be part of the 0.3 release

from extension-manager.

from extension-manager.

Looks like GNOME Shell is having some experimental mobile work done: https://blogs.gnome.org/shell-dev/2022/05/30/towards-gnome-shell-on-mobile/

It would be nice to support this use-case properly during the UI redesign.

I'm looking at reworking the UI after 0.5 as it fixes some issues raised by the GNOME Circle review.

Edit: The app is already reasonably responsive. Making a proper adaptive UI should (hopefully!) be straightforward.

from extension-manager.

Accidentally made this while working on the details view:

I'm thinking it might be cool on larger screens to have details on the right and a sidebar with search results on the left.

Food for thought.

from extension-manager.