Balsa UI changes - developer needed

[Wookey <wookey aleph1 co uk>]

Hi again people,

I mailed a few weeks back about how we are using balsa as the mail client on
a small-screen portable touchscreen device.

This project has a UI man going over all the apps to try and generate
consistency and make UIs easier to use, especially for 'normal users', often
coming from a Windows PC background. This mostly extends the gnome ethos of
simplifying interfaces to the things people really want to do, and hiding
more complex 'power' options deeper in menus. It also incorporates a few
good features from psion/EPOC/Symbian handheld devices.

Some of the changes he suggests are probably suitable for the mainline as
being sensible on any small-screen touchscreen (one type of click) device.
Others will be specific to this project. We're keen to get feedback from
balsa developers about which things you think fall into which category.

I hope you'll find the UI comments helpful - the suggestions are strongly
intended to be for discussion, not a list of demands.

We'd also really like it if someone familiar with the codebase stepped
forward to make such changes - we can do it ourselves but it'll take
longer, and is unlikely to be done as well as by those familiar with the app
and its code. I did mention this before but no-one volunteered. Real money
is available...We are in a tearing hurry of course, so some significant time
available in the next 2-4 weeks is a necessity really. Roll up, roll up.

Anyone interested in the work side of this, please mail me offlist with some
info on what you do and don't know about, when you have time available and
your rates.

The UI discussion can be more general of course. We have been working with
2.0.17 (debian unstable). Some of what we want may be in the 2.1 build and
it may make sense to move to that, but I'd need convincing that it was at
least as stable as 2.0.17.

Bugs
----

We have one major bug problem which is that any attempt to open an
HTML mail segfaults after a strange message about pallettes. This is pretty
fundamental and we're trying to track it down now - it is almost certainly
arm-specific. More on that as soon as we have something concrete to report.

UI discussion
------------

There are two relevant UI docs that I can make public - these are now here:
(as the original word docs)
http://www.aleph1.co.uk/armlinux/docs/Slash_Design_UI_change_spec_All_apps.doc
http://www.aleph1.co.uk/armlinux/docs/Slash_Design_UI_change_spec_Balsa.doc
(or as html)
http://www.aleph1.co.uk/armlinux/docs/Slash_Design_UI_change_spec_All_apps.html
http://www.aleph1.co.uk/armlinux/docs/Slash_Design_UI_change_spec_Balsa.html

These comprise some quite detailed discussion on the general principles for
the device and a lot of things about balsa that we'd like to change. They
are good because discussion and justification is given for changes, but they
are quite long. For those who can't be bothered reading that lot, here is a
summary of the overview and some of the more important points to give you
some idea of where we are coming from.

The target users are people used to office desktops, which generally means
windows+outlook+word+ie sort of thing. The device is intended to be very
easy to just pick up and use. Research has shown that most users are scared
by all the icons/toolbars/taskbars/window-furniture/buttons on their desktop
- they have no idea what most of them are for and often find if they push
things that 'things go wrong' and they have no idea why or how to put things
back how they were. So the UI must not make unexpected changes, and not have
loads of things on toolbars that only rarely get used.

There is also little screen space, and the screen (800x600) is physically
small (17x13cm or 6.5x5 inches) so the pixels are small making everything
look a bit smaller than on a desktop screen. To make a touchscreen useable
by a finger active areas/icons need to be at least 24x24, except for things
like borders which it's just not practical to move with a finger.

The window-manager only allows whole-screen switching - there are no
moveable windows - everything except dialogs is a maximised window and stays
that way. So you get app-switching, rather than window-moving. This means
that the message window in balsa completely obscures the overview window,
for example.

We also have a sort of 'halfway-dialog' concept (from epoc/symbian) that
pops up messages but in a less obtrusive way than a dialog (you don't have to
clear it). This is a useful idea that more apps could probably take
advantage of - currently available via a GPE library.

So, with that background, the balsa changes are things like. 
1) Not changing the ordering of in, draft, out, sent, trash boxes in the nav
window (consistent positioning)
2) Show numbers of new/existing messages in these automatically (you have to
click on them at the moment)

3) Quoting directly from the doc:
--------
Displaying attachments
       
Outlook and others just show you the text of the message (in whichever
format it best can), and indicate if there are any conventional
"attachments".
       
I want very much to do those two things. Balsa does the first already
(ISTM - doesn't it?) But not the second- attachment symbols appear on almost every
email in the list.

Can Balsa look into the contents of each mail, and then do better - eg maybe
something like:

Only display attachment symbols in the list by emails that really have them, and:

  Handle "message parts" differently when there are attachments - eg
  by adding a third tab, "Attachments", which just lists them, and
  lets you click them? (And ideally, by then not showing the "Message
  parts" tab for ANY message, unless some "Show message parts" option
  is ticked in Tools|Options?
		
  When there are attachments, we should call that second tab "Attachments".
  And it should not list things like the plain text version of the main e-mail
  (or any other version like HTML). Just attachments - every other email app
  just shows you the message, and then the attachments.

  So, no "mixed parts". (And the other tab should be called Message, not
  Content.)

If there is a reason why Balsa is the way it is, here, please let me know
what it is. Or perhaps you have better ideas on this topic?
---------

I expect this change is a non-trivial amount of work, and I'd very much like
to talk about the best/least painful way of making some change
to improve the useability here. Maybe there are already options?

4) Don't change the message sort order without asking (when e.g. 'date' tab is
clicked on) - this just confuses the user who suddenly 'loses' their mail. 

5) Currently if there is no connection to the net then trying to send a
message results in a very long delay watching a dialog - some way to give up
faster, and try to deliver automatically later would be good - how feasible
is this?


So- I hope that gives you some flavour of the sort of changes we want to
make for our platform. I hope some of you can help make those changes,
preferably in double-quick time :-) I hope some of the feedback is useful
for 'standard balsa' as I think most of the ideas fit fairly well with the
Gnome HIG ideas.

If anyone is interested to talk directly to the UI guy, Nick Healey, about
this then feel free to mail him, or I can give you his phone number off list.

Sorry this has been a very long mail. I hope it's useful to both the balsa
project and ours.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/