Updates page discussion

[madsrh]

These are not the greatest mockups, but hopefully you'll get the idea, which is to hide all the nerdy details from the average user. The buttons could also be placed near the top of the window. The Sources list have been moved into settings.

I've moved the checkboxes to the left side like this example. Expanded:

It would be really cool if new releases would get a "banner" by grabbing the latest artwork from the Ubiquity slideshow here. If it can't connect, there's would ofc be a fallback image.

While installing updates, some advanced users may want to following along in the "command-line". Inside Settings there should be an option to enable this (so the expand arrow > is really unnecessary here since the user have actively enabled this).

[Feichtmeier]

After https://github.com/ubuntu-flutter-community/software/pull/606
We now also have snaps in a list to update. They could ofc always be updated in their landing pages. But this gives a view to update them all at once

Should we unify the views to have the same look?
Please don't even think about putting them into the same tab :)

[madsrh]

Incoming potentially controversial suggestion 🙈

The current design is looking great, but I think that the second tab is a too hard to find.
If the user doesn't find it, they only see the snap tab and might think their system is up to date (because you have to press the check for updates button for the badge to appear). Also, you can see why this is a confusing screen.

Even if it's two completely different package formats, we should discuss the discoverability issue here. I would suggest unifying the two package formats on one page. WDYT @anasereijo @Feichtmeier @Jupi007 ?

SIDENOTE: I think there's something odd about the position of the two button in the top, but I don't really have a good solution.

[madsrh]

I've seen your 👎 😁 and I'm at peace ☺️ I've pointed out my thoughts on the issue and I have no understanding about what's technically possible ✌️

[Feichtmeier]

Yeah it's a tough task we have here. We need to iron out this weird software 📦 package stack on Ubuntu. But often you can not iron it out with the UI. You see on every aspect that modern package formats are superior to the old ones. I personally hope that the whole Ubuntu desktop switches to snaps someday

[madsrh]

Just to be clear @Feichtmeier, you do know that I don't mean merging both packages in the backend. I only meant reorganizing the frontend UI. Everything stil running totally separated - like now, just on the same page 😺

[Feichtmeier]

We don't have any control over the Daemon processes anyways. The snap Daemon talks to the store but also manages the snap apps . Packagekit talks to apt reads the Ubuntu Debian repos.

Yes I know what you mean but since merging the view requires merging the APIs in our code the result will be not good. The snap Daemon works totally different when it comes to updates. As I said you only can ask it for what the changes are. Just let's not do this. For all the reasons I've mentioned above

[Feichtmeier]

Everything stil running totally separated - like now, just on the same page

When you say separated. Do you mean like a split screen? This could work but already the update checking runs on a totally different schedule and timing and also will vary in three length of the checking very much.

Checking for update on one split screen⏰

Checking for updates on the other split screen : ⌚

Updating this list will thus be slowed down by at least double. I don't think this is worth it. For what? Snap updates are basically a feature for people that can't wait, because they will update anyways on their own. Debian package updates, which are also system updates, will come from the outside 🔜

[Feichtmeier]

Woah so many things happened 😄

I am happy with this

However I am not happy with this

->

Even if I love the update screen design we've accomplished there it feels like an extra step and maybe the simple design of the snap installed/updates page should be used here aswell? Would mean no fancy images and animated check mark screens

@madsrh @anasereijo @Jupi007

[Feichtmeier]

The problem why we still need to special case debs is that you can easily get hundreds of package updates. This never happens with snaps, unless you install hundreds of snaps. So for debs we def need the expandable + checkbox IMO

I take care that the list tiles have a unified look

Grids are great but also not so great for a focused view. Maybe here a compact list is better for the visual focus

[anasereijo]

Just an idea... Could we hide the button open when it's disabled? That will 'break' the grid, so we can change the order of the buttons to: Update, Open, Remove? WDYT

[Jupi007]

The problem why we still need to special case debs is that you can easily get hundreds of package updates. This never happens with snaps, unless you install hundreds of snaps. So for debs we def need the expandable + checkbox IMO

Hmm, but are we talking about the same checkbox? :D
I mean the one which trigger the deb update view, just against filters dropdown.
I don't mean to remove the ones which allow to select/unselect updates themself.
Also the deb updates expandable should be collapsed by default, as it can be very huge, and so hide installed apps.

Edit: just like in your screenshot, where you removed this checkbox:

[Feichtmeier]

Yes ofc this one needs to go 🙂

[Feichtmeier]

@anasereijo

Could we hide the button open when it's disabled? That will 'break' the grid, so we can change the order of the buttons to: Update, Open, Remove? WDYT

Yes good idea! I will do when my first attempt to unify snap and debs is through 👍

[Feichtmeier]

This is a weird take but.... did we ever talk about if we maybe just don't want to include this whole system & updates and deb updates in the software store app?

1. The current tools work well and the UI is not super ugly
   
   

2. Those system updates (which weirldly also include software that comes from PPAs like chrome and lutris) are critical to work well and can f*ck your whole system. So the current software is well tested and pretty rock solid

3. Our software store can not help the fact that the concepts of "system updates" and "app updates" are so mixed and blurred with classic packages like debian. We try to mitigate this with UI but we can not change this.

4. At some point in the future those things will hopefully be covered by snaps for ubuntu

Hot and controversial take but we are here to talk and discuss so 🤷

WDYT @madsrh @anasereijo @Jupi007 @d-loose @local-optimum

[local-optimum]

Yes I was discussing with Ana and others that we are representing updates across multiple apps and whilst it might be nice for some of those features to be merged with the store as the primary location, for now it would be easier to point to existing apps for things like:

• deb updates
• PPAs

eg we could simply prompt the user to run 'Software Updater' or open 'Software & Updates' in the two cases above. Long term we need to also address the number of apps named 'Software XXXX'.

[madsrh]

IMO the spinner in Collections seems a bit oddly placed. It looks like it has two functions "page content loading" and "check for updates", so maybe we should place it inside the "check for updates" button and use the shimmer / loading skeleton for when the page is loading. WDYT?

[madsrh]

...to display it when there's no update

That's what I don't understand. IMO that is two separate things. You can always check for updates because after one minute there could be new updates. So if we want to write "You're system snaps are up to date" then we should still show a "check for updates". But I like the idea - just not inside the button 😄

[Jupi007]

But I like the idea - just not inside the button smile

Ofc not inside the button 😄
I would see it in a row, below the buttons one.

[madsrh]

So, something like this? (like the first post in this thread 😄 ) I do feel it's a bit too heavy on the left side.

Do we need a clear distinction between updates and installed apps or is that already obvious?

[Jupi007]

Do we need a clear distinction between updates and installed apps or is that already obvious?

I think it is a good idea to add some title/label to sections 👍

[anasereijo]

@madsrh I agree – having the title on each section helps to make it clearer 👍
I would simplify the labels to:

• Updates
• Installed

what do you think?

[madsrh]

Hello everyone

I've been chatting with @anasereijo (and @Jupi007) about some ideas for the update page. Some ideas are my own, so don't blame them if they are bad. Thoughts for discussion that can eventually be turned into issues:

• move checkboxes to the left
• add section labels above Updates and Installed (also for snap page?)
• refresh icon and spinner inside the "check for updates" button
• use packageformat toggle (UpdatePage: switch appformat dropdown to toggle button #1080)
• remove icons (almost all are fallback anyway) - only keep security sheilds
• hide the version (available in changelog - also how the current updates are shown)
• show package size and total download size (alternative styling ideas)
• page loading skeleton rather than spinner
• Fixed max-width (like the AppPage has)

Things I would love to see in the future would be; sane descriptions 😄 and sub-grouping/tree structure - like the current updates has.

WDYT?

[anasereijo]

One question/thought:

For the updates, what about we provide 2 options:

• update all button
• update individually each app

So instead of providing the checkboxes for all pending updates, users can either update all or update one by one. Just wondering if we are overthinking here, trying to make the checkboxes look nice and work.

apologies if this was already explored or discussed.

[Jupi007]

It doesn't make sense to update a single deb. Have hundreds updates can be a common case, and 99,9% of the time, you just update everything.
The common use case of checkboxes is when you specifically don't want to update a single package. It is in this way that they are used.

BTW, I think we should remember which update are unchecked, it is in this way the current software updater works.

[anasereijo]

yeah, you are right - thanks!

[Jupi007]

Debs are really philosophically different from snaps. They are mixing dependencies and apps.
If we could separate apps from dependencies into the update view, it could make sense to update a single app. Even if update an app require to also update its dependencies...

[anasereijo]

Hmm, I'm not 100% thrilled about moving the buttons into the title

I agree @madsrh. I do worry about moving the package type buttons into the title — feels to me inconsistent. 🤔

I get the point of looking a bit strange having the package button 'alone' but between both options I think it's best to keep it in there. Would it help to balance a bit more by having a label before the button? Something like 'Package format:' or something like that?

just a thought

[Feichtmeier]

CurseForge.2023-03-26.10-35-35.mp4

I really like the way updates are removed after done here

[madsrh]

This looks very slick 😎 Where is your PR? 😜