[Design-team] Fedora GRUB2 boot menu, from design perspective

Kirk Bridger kirk at thebside.ca
Thu Jun 21 04:32:32 UTC 2012


Hi Máirín,

Thanks for the link to the user base, that's actually new to me (or I've 
forgotten about it) - a good resource.

I don't see any specific info that would help answer some of the 
questions we've uncovered in this discussion.  It would be great if we 
could reach out to Fedora users to answer questions such as:

1 - How many operating systems do you typically have installed on your 
main machine?

2 - How often do you use the ability to boot your machine into older 
kernels?  Other OSs?

3 - What causes you to boot into old kernels?

4 - How often do you select something other than the default in the boot 
menu (i.e. grub2)


The questions might need some polishing, but those are the ones I can 
pick off the top of my head.  A quick survey might get some valuable 
data here.

I'm not sure if there is an actual project waiting for our input here or 
if we're just discussing things, so maybe we have some time to collect 
some data?

I like the idea of relating the old kernels with the rescue concept.  I  
suspect you're right that most users don't use old kernels (is there an 
auto-prune for this, like keep the last 3 kernels only?).  They probably 
only access those when something goes wrong with the latest kernel, like 
in a rescue situation.  I've had to access old kernels myself and I'm 
certainly no developer, so the use case exists (I can't be the only one!?)

I guess the core of my concern is that we are cleaning up clutter for 
users who don't mind the clutter, or actually want the clutter.  I want 
to avoid designing for ourselves by focusing on our actual user's needs 
and tasks.  Maybe I just lacked the knowledge about the user research 
that has gone on prior to this discussion.

What are your thoughts on the need to collect some data from Fedora 
users via a survey?  Useful or redundant?

Thanks,

Kirk



On 06/20/2012 07:30 PM, Máirín Duffy wrote:
> Hi Kirk,
>
> On 2012-06-20 19:04, Kirk Bridger wrote:
>>  1 - I think data should be collected before we make assumptions about
>> our user base.
>
> We need to take the user base as defined by the project board as a given:
>
> https://fedoraproject.org/wiki/User_base
>
> It wasn't determined lightly and it was researched and deliberated and 
> discussed throughout the community pretty carefully.
>
>>  2 - I think categorizing is a better solution than hiding, as users
>> with lots of kernels/OSs are more likely to be switching more often,
>> vs users with just a few.  The value of reducing clutter is minimized
>> is clutter consists of 3-5 items, and hiding things makes it harder to
>> do what you want to do.
>
> Don't forget to consider, along with majority of users vs minority of 
> users, how frequently vs infrequently users will be:
>
> - Switching OSes
> - Switching kernels
>
> I believe switching OSes is going to be more frequent for even the 
> Pokemon 'gotta catch 'em all' distro enthusiast than switching kernels 
> within each OS, and the mockup that Martin put together definitely 
> optimizes for switching OSes instead of switching kernels. The only 
> user I know of that realistically switches between specific kernels on 
> any kind of frequent basis is a kernel developer, and I haven't seen 
> any complaints or concerns from kernel developers about the change. 
> That being said, I can certainly reach out to a few and get some 
> feedback from them, but I think they probably - since their menu has 
> so many entries anyway - have highly customized grub conf files anyway 
> so any defaults are likely not to affect them.
>>
>>  3 - I think removing clutter is a good goal, provided it meets our
>> users needs (see comment #1)
>
> +99 I'm glad we seem to be all on the same page about this part, we 
> just need to sort out more of the other details.
>
> ~m
> _______________________________________________
> design-team mailing list
> design-team at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/design-team


More information about the design-team mailing list