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

Re: UI enhancements



On Mon, Sep 03, 2007 at 10:17:43AM +0200, Thomas Roessler wrote:
> 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.

Certainly.

> However, the question at hand is how to make a specific interaction
> fit the rest of the interactions that people have with mutt.  

Well, Rocco seems to be suggesting that Mutt only use this new
functionality in certain places, but I would agree that Mutt's
interface should remain consistent -- I think it should pop up dialog
boxes like this everywhere it needs to prompt the user... including
when it displays errors in a curses context.  There are (or used to
be) error messages that would pop up in the status line that would
disappear before the user could read them, or in some cases even
notice they were written to the terminal...  The dialog box paradigm
is a good way to avoid that problem entirely.  In general, I think
it's just a much better way to interact with the user.

> 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.

That's quite reasonable. :)  Someone would need to code the
alternative, of course...

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

Yes; it did sound a bit to me like you were suggesting that, even upon
a re-read.  And to be fair, in the past you have by all appearances
not included useful features evidently on the basis of your personal
preferences alone...  I'm not saying you couldn't have had other
reasons, but if so you were very often rather quiet about them.

> De gustibus non est disputandum. ;)

Indeed. :)

> >>> 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.

Well, in my xterm, bold text is displayed as colored text... so it
kind of does, and it kind of doesn't.  I'm aware that there's a
resource one can set to make bold show up as bold, but how effective
this is seems to be rather variable, depending on what fonts the user
has selected for xterm to use, and apparently also the alignment of
the stars and a confluence of other less-predictable events... 
In theory it can/should take care of italics in the same way too, but
again, your fonts have to be right, and I guess mine aren't... ;)

I think gnome-terminal and konsole are a bit better about that, but
those options suck for a variety of other reasons (insanely slow text
rendering, less configurability, lack of availability on various
platforms, etc.).

As an aside, thanks to Thomas Dickey for keeping xterm in such
excellent shape after all these years... :)

> > 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.

But see above about rendering only *simple* HTML tags.  The great
thing about HTML is that implementations get to decide which tags
they'll render and which ones they won't.  They also get to decide
*how* to render them.  And of course there are well-defined standards
that outline how you *should* do it, if you do...  If that doesn't
cover what cases you're thinking about, I'm not sure what you mean.

> 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.

I agree completely.

The sidebar patch goes a long way to getting me what I want.  My main
frustration in using it is not with the sidebar patch itself, but the
way Mutt does new mail detection.  As I've said several times before,
I think new mail detection is completely broken, and the sidebar patch
is a constant reminder of that.  Anyway, another sidetrack...  The
only thing that doesn't get me is the ability to compose a message
while viewing other parts of Mutt's UI (another message, or the
message index, or whatever).  If a clever way to provide that
functionality were devised, I think that would be extremely cool...
but I can live without it, since as someone pointed out, I can start
multiple instances of mutt in different windows (or screen, or
whatever).

However, if Mutt's interface were more modular, you could include an
optional GUI that did all of these neat things, and more, for the
cases where the user is running Mutt locally and wants to have them.
When the user is remote and/or doesn't want all the extra overhead,
the terminal-oriented UI would remain.  You get the best of both
worlds.

> 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.

Well, new mail detection, for one, could more easily be fixed.  I
guess it's actually relevant (not to the discussion of Rocco's patch
per se, but the broader discussion of UI enhancements), so I'll
elaborate.  But this is only an example... there are other such places
where improved modularization would benefit even the current UI
design, though none so striking as this.

Mutt does a cool thing: when changing folders, it cycles through
folders which have new mail, in the order you define them in your
muttrc (unless you tell it to use some other order), which provides
the functionality of telling you about folders with new mail in the
order of importance of those folders, if you use it that way (which I
obviously do).  This is great.  But it has some problems.

The first problem is how Mutt decides whether a folder has new mail in
it or not... Mutt's idea of a folder with new mail in it may be
different from the user's.  If a user marks a message as new in a mbox
folder, Mutt will not recognize that folder as having new mail in it.
Notice I specified mbox... this leads to problem #2.

Mutt's new mail detection is not consistent across mail folder
formats.  In general, aside from optimization considerations, the
folder format should not change the behavior of the program.  In
particular, the interface presented to the user should not change just
because the format in which the data is stored has changed.  This is
just bad program design.

Problem #3 is that Mutt can not distinguish between new mail and
unread mail, regardless of of the folder format used.  Ideally, I
would want Mutt to cycle through folders first which had actual new
(unseen) mail in them, then by folders that had unread (but seen)
messages in them.  

At work, I have to monitor a variety of mailing lists, each with a
different importance, and each requiring different response times,
generally.  With the current interface, if I want to move on to new
mail in less important folders than the one I'm reading, but I have a
message in this folder that I want to put off addressing (or just
haven't read yet), then in order to be reminded that I have important
messages that need my attention, I need to use maildir and leave those
messages marked as new.  If I don't, due to the usual distractions of
the day and the volume of mail I receive, I'll forget about the
message.  If I use mbox, Mutt will "forget" that I still have new
(unread) mail in this folder, so using Maildir is the only option.
But this is not a good solution, because Mutt will now cycle me to
this mail folder first every time I try to change folders, even if it
does not actually have genuinely new mail in it.  The only way I can
tell if it has actual new mail is to re-enter that folder and look.
This is highly inefficient, and when you're dealing with roughly 500
messages per 8-hour shift, the effect it has on productivity is not
negligible.

Granted, it's still way, way better than trying to do it with Outlook,
which some of my coworkers do.  I don't have any idea how they manage
it. ;)

> > 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.  :)

OK, it doesn't need to be completely abandoned, but a lot of the
current core would need to be rewritten as a lot of functionality is
tied directly to the interface.  It needs to be separated/abstracted
so that the interface can change without the underlying functionality
needing to change as well.
 
> Good luck. :)

Indeed...

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

Attachment: pgpEqjewbpPR8.pgp
Description: PGP signature