UI Redesign (1.0)

[Leleat]

Hi,

Since you are using libadwaita it makes sense to follow GNOME's design language more closely. Don't know how far ahead you thought about the design but here are my 2¢ about it. (I did see you posting on GNOME Shell's extension issue. So if you got contacted by a GNOME dev, just ignore me since they'll probably have their own design plans 😉)

My idea can be summarised as "Because your app is basically an extension store, you can just copy GNOME Software (instead of GNOME's extensions app)".

• I think you can unify the rows of the Installed and Browse page. Currently, the row of the Installed page expands to reveal the description, a 'See Details' and a remove button. The description isn't useful for extensions you already have installed because you likely know what you installed. So essientially you have a revealer for 2 buttons, which IMO isn't worth it. Also, that means the Details page is 2 clicks away. My suggestion: instead of an expander make the row always go to the details subpage.

• I think unifying the Installed and Browse page in general make sense. I. e. having a global search like a normal app store etc...

• Spacing between items is sometimes off. GNOME (unofficially) uses a multiples of 12, sometimes 6.

Here is a mockup I created to illustrate my ideas more clearly. I am not a designer so sometimes I was inconsistent when it comes to spacing, shadows and what not...

[mjakeman]

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?

[Leleat]

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.

[Leleat]

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)

[EvgenySurgut]

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!

[mjakeman]

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

[EvgenySurgut]

Good! Well, in general, your application is just super! And the new icon is great! You are well done! В Чт, фев 10 2022 at 23:11:42 -0800, Matt Jakeman ***@***.***> написал:

…

@EvgenySurgut <https://github.com/EvgenySurgut> There's a new GNOME-style app icon as of #84 <#84> (and #99 <#99>). This will be part of the 0.3 release — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWG7MELL2FBTCXKF2XW2SHDU2SZC5ANCNFSM5MWGDJNQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mjakeman]

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.

[mjakeman]

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.

[mjakeman]

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