Jeremy Katz <katzj <at> redhat.com> writes:
> You're missing my point here... the idea _ISN'T_ "how does the UI mock
> up match with the use cases". It's more "determine the set of use
> cases. Based on them, work on the actual interface". You _start_ with
> the use cases, not the mockup.
Except that the "mockup" is inspired by an existing UI (Synaptic) which has
been used successfully for years, and which IMHO is one of the best (if not the
best) package management UIs out there.
> The idea with pirut has never been to provide "the functionality of the
> CLI wrapped up in a GUI". Rather, we want to expose the things which
> are good for the majority of users. If you need every bit of
> functionality of the CLI, then really, you're probably a better target
> user for the CLI not pirut.
Why artificially restrict the target user base for Pirut this way? Wouldn't it
be better if Pirut was useful for everyone? Right now it really isn't, and
Synaptic, Yumex or smart --gui are much better options for experienced users.
> Lots of options is _not_ the answer to making a tool attractive to
> "non-newbies".
I also disagree with the assertion. Configurability is an important feature for
power users. This is working well for KDE, Synaptic and many other software
packages.
Another method of dealing with the different requirements of new and
experienced users is to do what Firefox does: present a basic UI by default,
but make it extensible by dozens of extensions. The yum CLI also uses this
design to some extent. I personally really dislike this though, both because
hunting down extensions/plugins is a pain (much more than checking an option
somewhere) and because some of the functionality provided by the extensions or
plugins should really be on by default (and able to be disabled by experienced
users), take yum-skip-broken as an example. But IMHO even this design would be
an improvement over the current Pirut.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
