<<< Date Index >>>     <<< Thread Index >>>

Re: UI enhancements



On 2007-09-03 01:15:32 -0400, Derek Martin wrote:

>> It's not about noticing, but about causing minimal confusion.
> 
> It's hardly confusing.  The typical user is highly accustomed to
> interacting with GUI applications, virtually 100% of which have
> dialog boxes pop up either in the middle of the main window, or
> (more commonly) in the center of the screen.  

You're arguing why mutt should have a completely different UI
paradigm, which -- surprise! -- might even make sense if it was
started from scratch today.

However, the question at hand is how to make a specific interaction
fit the rest of the interactions that people have with mutt.  And
for that, it's more critical to be consistent *inside* the program
than to be consistent with curses applications around it.

(To give just one example, emacs -- which shares some UI paradigms
with mutt -- has an occasionally-extending status bar.)

In any event, as I said before elsewhere, I'd like to see the two
options (center of screen and bottom of screen) in place for a
while, so we can actually see what makes more sense.

> A great many curses-based terminal-oriented programs behave this
> same way. This is now decades old, well-established,
> cross-platform behavior.  Saying it is more confusing is like
> saying the Metric System (SI units) of measurements is more
> confusing than the English System... it just isn't.

Using the metric system in the middle of a conversation that's
otherwise using miles and feet is, indeed, confusing...

>>> FWIW, I've also always wanted Mutt to have a multi-paned
>>> interface, not unlike most GUI mailers: one pane for the
>>> folder list, one for the message index, and one to display
>>> messages.  

>> Incidentally, I wouldn't want to have that particular kind of
>> UI for myself. 

> But lots of people would, hence the popularity of the sidebar
> patch, which is standard on Debian's build of mutt.  And the
> point is it would be configurable, like everything else in Mutt,
> so you don't need to use it if you don't want to, and you can
> even enable/disable it on the fly, if you want to use it some of
> the time... much like you can do with GUI mailers, by dragging
> the pane frames around to hide or unhide the various frames.

I think you constructed an objection to including that patch from a
simple remark about my personal preferences.

De gustibus non est disputandum. ;)

>>> Mutt could do some (extremely) basic HTML formatting, like
>>> handling <b>, <i>, and <tt> tags, and displaying inline
>>> images. Yeah yeah bloat blah, but it's just a lot more
>>> convenient if I don't have to launch external applications to
>>> view these extremely common forms of e-mail.  

>> Use "lynx -dump -with_backspaces" as your default html handler.
>> :)
> 
> This doesn't display italics on my terminal, nor does it display
> bold as bold text.  

It should actually take care of bold.

> That kind of eliminates the usefulness of using formatted text to
> highlight and emphasize selected text over the rest...  I could
> probably futz with my terminal configuration to make it display
> that way, but I don't *want* to.  By contrast, the GUI mailers
> just work as expected, in that regard.

True.  They also work as unexpected, if you look at the various side
effects that HTML can have at times.

>> From a design perspective, that handler should actually be an
>> external filter.

> That makes sense for the Mutt of today (or rather 10 years ago),
> but makes very little sense for (say) a GNOME-ized version of
> Mutt which is (optionally) already linked against all the happy
> libraries that handle HTML formatting and JPEG display, etc.  The
> point of Mutt's design (and the Unix philosophy, in general) is
> modularization -- making small, easy-to-test bits of code that do
> one job, and do it well...  But modularization can just as
> effectively be handled by using good software engineering
> principles to write modular code, and using any of a plethora of
> well-tested libraries to accomplish tasks that Mutt currently
> accomplishes using child processes.

As much as I'd love to get more into that discussion...  Let's leave
it on the sidetrack that it's on right now. ;)

> The current "design perspective" of Mutt was born in computing's
> Stone Age, and is sorely in need of updating.  

That mutt is starting to show its age is doubtlessly true.  That its
heavy reliance on a single text terminal is quite limiting is true
as well.  At the same time, there are use cases where that
limitation is actually a plus, and I'd hate to see mutt become
unsuitable for these.

> It causes a variety of limitations that are not currently
> suffered by users of other, more modern (GUI) mailers.  Mutt is
> still the most powerful and flexible mailer around, AFAIK; but it
> is far from the easiest to use...  Mutt could continue to be the
> most powerful and most flexible mailer, and at the same time
> realize a great many improvements in ease of use and
> configuration management by letting go of its ancient design
> philosophy.  It need not lose its terminal orientation in order
> to do so, either. 

You could keep a terminal mode around, but I would be surprised if
all (or even most) of the benefits of an updated architecture were
to manifest themselves in such a mode.

> the current code base desperately needs to be abandoned, and a
> fresh rewrite started with modularity and modernization in mind.
> But that's a project -- and an argument -- for a different,
> brighter day.  :)

Good luck. :)
-- 
Thomas Roessler   <roessler@xxxxxxxxxxxxxxxxxx>