Re: UI Refresh

[Mathieu Jourdan <mathieu jourdan gresille org>]

Le 10/12/2019 à 03:07, Michael Terry a écrit :
> On Sun, Dec 8, 2019, at 14:14, Mathieu Jourdan wrote:
> > > > If I understand well, to exclude a file from backup, she would have to
> > > > "add" it to the "included files", and the turn the button off? Seems not
> > > > really straghtforward to me.
> > >
> > > That’s fair. I liked the idea of having the standard locations that you could turn off and on. Wasn’t 
> > > sure how best to add custom includes / excludes into that mix.
> > >
> > > Any ideas there or do you think the standard location items  aren’t worth it?
> >
> > Rough thoughts below.
> >
> > I think part of the difficulty may reside in mixing two different
> > approaches:
> > 1. based on content type (ie, "I want to backup my documents and
> > pictures and videos")
> > 2. based on file hierarchy (ie, "I want to backup all my personal data
> > of any kind but not these specific folders")
> >
> > With the first logic, the user wouldn't even have to exclude anything,
> > because that's implicit. With the second logic however, the only way to
> > perform an exhaustive backup would be to offer to pick up only
> > one folder to include. The user would then explicitly exclude any
> > subfolder she knows for sure a loss would be harmless.
> >
> > My feeling is that those two approaches don't mix well together.
>
> You say that in scenario 1, people wouldn't need to exclude anything. But I bet that it's not uncommon for 
> folks to have a Documents or Videos subfolder that they don't want to back up.

Then we would fall in the second case, because the user would be
conscientiously dealing with folders and file hierarchies.

Yet, not everybody would necessarily want to deal with file hierarchies,
neither exclusions. Nowadays people tend to use separate apps for
specific content, ie having videos, music, and podcasts (approach 1),
rather than launching a file browser to pick up a file to open with an
all-in-one media player (approach 2).

That's why I suggest it is to be expected people may use the same
reasoning when it comes to backups.

> Which makes those two approaches feel very similar. The big difference would be more like, do you have one 
> or multiple "include roots"? Where each root has its own little excludes. Maybe that is a decent way to 
> organize the UI? A set of "parents" with exceptions attached to the parent. Would have to think of how to 
> lay that out in a reasonable way...
>
> One goal with this redesign is reduce the amount of like, folder math, that people need to do, as I suspect 
> that's not an easy mental mode for most people. That's why I kinda like the big "on/off" switches for 
> common includes.

THIS. The thing I'm talking about above is all about considering
different mental models, to reduce folder math!

> Some other vaguely-related things to consider:
>
> - It's not uncommon to get requests to add regex include/excludes. So far, this is something I've resisted, 
> as I think it's a bit pro-level and have not thought of a very friendly way to show it in the preferences. 
> But here's a chance to think about that again.
>
> - It might also be a good  time to consider how we talk about hidden folders? Restoring them along with 
> your data files is tough, because (a) snap permissions (if we stopped being classic mode) prevent writing 
> to hidden folders in your home and (b) restoring over your active session's hidden folders can cause some 
> bugs as configs get overwritten in live time. This is more of a restore problem. But maybe if we also 
> separated it in the include preferences, we could set some user expectations for showing them differently 
> in the restore mode too. (I don't know how we want to solve that restore problem -- maybe have a separate 
> button/mode like "restore hidden files to somewhere which won't overwrite your current ones, but where you 
> can still do something useful with them" -- whatever that means)

Perhaps I'll find some time and ideas to make a couple of sketches, to
feed the reflexion.

> > > Prettier than our current UI for sure.
> >
> >
> > More observations on the refresh… I'm not sure how well the view
> > switcher would work:
> > - on the "backups" view, I would expect to find existing backups
> > - "restore" is an action, not a type of content
>
> Maybe having “Back Up” and “Restore” as the two view names would work better to solve those two points.

Something like "overview" and "backups" would better
fit imho, as view switchers are most of the time describing the content
that will appear in the view. Imperative verbs suit better to action
buttons. Though the HIG is a bit vague about this.

> > - having both a back button and a view switcher in the header bar
> > feels a bit awkward to me
>
> I hear you here, but that’s a GNOME design pattern these days. You can see it in Software, Boxes, etc.
>
> https://developer.gnome.org/hig/stable/header-bars.html.en

Software, Boxes, Music, Settings and others do use both back buttons and
view switchers. But as far as I know, none of them use both kind of
navigation controls at the same time. The view switcher is
always hidden when a back button is shown. The behavior of the back
button is more predictable that way.

--
Mathieu