Updated Prefs Proposal
Jennifer Glick
Fix some of existing 'items getting cropped' bugs
Plan for future 'items getting cropped" bugs as new items get added
Rewording and/or grouping of items
Plan for expected future prefs
http://www.mozilla.org/mailnews/specs/prefs/PreferencesP.html
Thoughts appreciated,
Jen
Marius Strumyla
i have some comments on two options Text Format and Compose.
* Text Format
i'd like Text Format to have a new concept "message view format" in
addition to "message send format". in other words, i'd like to combine
these two into one. if my message view format is plain text, that
implies i want to send a message in plain text. sorta "what u see is
what u send" concept.
Preferred Message View
(x) plain text
( ) html
( ) mixed.
( ) plain text
when this selected, that would mean that a user prefers to both see
and send messages in plain text. when user gets an email in html, he
would see the html source. (well, that's what he selected.)
when user sends a new message, it is sent as text.
( ) html
when this selected, that would mean user sees html messages as html.
text messages are converted to simple html.
when user sends a new message, it is sent as html.
( ) mixed
when this selected, user sees text messages as text and html messages
as html.
when user sends a new message, the message format could be determined
from already existing HTML domains and Plain Text domains lists. when a
user replies to a message, it should preserve the format of sender's
message.
i think it would be simpler.
* Compose
this is a verb. menu names should be nouns. all the rest names are nouns
except this one. what was wrong with Message Composition or Composition?
--
i5mast
Ben Bucksch
> Preferred Message View
> (x) plain text
> ( ) html
> ( ) mixed.
Bug 30888.
Andrea Monni
You should expose the UI for turning on and off the structured words
(*bold*, /italic/, _underline_); and also the ability to choose between
different maps engine for the "Map It" funcionality.
Andrea
--
Andrea Monni <andre...@yahoo.com> "It is our choices, Harry, that
Y! IM: andreamonni show what we truly are, far
ICQ: 7387142 more than our abilities."
Tiscali NetPhone: 178-229-5413x165 A. Dumbledore
Matthew Thomas
>...
> http://www.mozilla.org/mailnews/specs/prefs/PreferencesP.html
>
> Thoughts appreciated,
>...
In general this design is slightly cleaner, and it certainly fixes the
current problems with overflowing panels (though your mockups seem about
20 pixels taller than the allowed size of the dialog). However, the
redesign repeats several of the problems in the current prefs, including
overuse of group boxes, bad indenting of option buttons and checkboxes,
and wording that isn't as clear as it could be. It's also troubling that
there are more panels in the new design than the current one; you should
be aiming to decrease the number of panels, not increase it.
Specific points:
Unnamed
-------
1. `Confirm when moving folders to the Trash' doesn't really make
sense. Confirm what? Confirm that the folders are empty? Confirm
that there isn't already a folder in the Trash with the same name?
I think you want `Warn me', not `Confirm'.
But remember, the whole idea of having a Trash in the first place is
so that you can have both confirmation and undo when deleting stuff,
*without* having an alert. So:
- If it's too easy to move a folder to the Trash, then make it
more difficult -- for example, by making the keyboard shortcut
accel+Delete instead of Delete.
- If it's not clear enough that a folder is being moved to the
Trash, you need to improve moving feedback in general, using a
progress window, and/or zoom rects (like MS Office 2000 when
you Save As or do background printing), and/or the OS's sound
effect for trashing, and/or expanding the Trash folder in the
folder pane whenever a folder is moved to it.
2. The `Confirm when using keyboard shortcut to send message' (you mean
`Warn me' here again) really belongs in the `Compose' panel, not the
miscellaneous panel.
3. The `Mail Start Page' group box could be simplified from this
_Mail Start Page_________________________________________________
| |
| [/] When Mail launches, show the Start Page in the message area |
| Location: [about:blank ] |
| ( Resto_re Default ) |
`-----------------------------------------------------------------'
to this
[/] When Mail launches, show this page in the message area:
[about:blank ] ( _Use Default )
This would make the UI simpler, and remove the need for users to
learn what the `Start Page' is in one control before transferring
that knowledge to the next control.
4. Since the the URI field and `Restore Default' button are obviously
children of the Start Page checkbox, there is no need for a
content-free `General Settings' group box around the other
checkboxes.
Window Settings
---------------
5. The `Window Settings' group box is completely redundant, since it's
not separating the items inside it from anything else.
6. `Select the window layout you prefer for Mail:' is wordy and a bit
authoritarian. I suggest `Window layout:'.
7. `Note: For this setting to take effect, you will need to exit and
restart Mail.' is wordy and a bit inaccurate. I suggest `Changes
take effect when you open a new mail window.'
8. When a changed setting takes effect on a restart or similar, the
standard method of marking the explanation (on both Windows and Mac
OS) is with a miniature /!\ icon, not with the text `Note:'.
9. Finally, I would estimate the amount of work required to make this
pref take effect at the same time as the other prefs, rather than
when a new mail window was opened, would compare favorably with the
amount of time required to implement the prefs redesign. :-)
10. The option buttons in this panel are indented too much. Such
indenting is appropriate for assistants on Mac OS, but not for any
other kind of UI on Mac OS or on any other platform.
Message Display
---------------
I am still of the opinion that this panel shouldn't exist: most of the
settings in it are those which need to be changed quickly (i.e. with a
menu item) rather than in the preferences, and the remainder are
duplicates of items which are (or should be) in the Appearance branch
rather than the Mail & Newsgroups branch.
11. The `Plain Text Messages' group box is completely redundant, since
it's not separating the controls inside it from anything else.
12. The option buttons and checkboxes in this panel are indented too
much.
13. The last checkbox should not have any periods in it. The example
should be a <description> indented underneath the checkbox; it
should not be part of the <label>.
Compose
-------
14. Names of panels should be nouns, or at least present participles.
(That's why `Offline & Disk Space' is awkward, and it's one of the
reasons why `Advanced' should die.) `Composing' or `Composition'
would be much better.
15. In `Forwarding and Replying to Messages', `to Messages' is
redundant.
16. ... Nah, I can't itemize this panel. Here's an alternative
suggestion. It uses more group boxes than I'd like, but all of them
are actually doing something useful, and I think the greater clarity
is worth it. The most important change is that the 8-bit handling is
presented with option buttons rather than a checkbox, since it's an
either/or choice rather than an on/off choice.
_When forwarding_________________________________________
| |
| Include the original message: [ as an attachment :^] |
|_________________________________________________________|
_When replying___________________________________________
| |
| Quote the original message: [ above what I type :^] |
|_________________________________________________________|
_When sending____________________________________________
| |
| [/] Check with me if I used the Send keyboard shortcut |
| [/] Wrap plain text at [ 72] characters per line |
| [/] Check spelling before sending |
| |
| Send 8-bit (non-ASCII) characters: |
| ( ) verbatim |
| (may not display correctly on some computers) |
| (*) using "quoted printable" MIME encoding |
| (results in larger messages) |
|_________________________________________________________|
Text Format
-----------
17. This panel probably should be called `HTML Formatting', not `Text
Format'.
18. The options which you have put in an option menu really really need
to be displayed as option buttons instead, so that the pros and cons
can be described under each option.
Now, there are two ways to make room for those option buttons. As I
have said before, if the domain editing UI remains as it is, I think
it should go in a separate dialog opened from a `Domains...' button.
However, if someone's smart enough to set up domains for sending
plain text and HTML mail, I think they'll find the current UI a
tedious way of doing it. Instead, I suggest asking for a
comma-separated list, just like the list of domains which Mozilla
should not use a proxy for. Two text fields would take up much less
room than two listboxes and four buttons.
Autocomplete
------------
19. Despite programmers' usage to the contrary, in the real world
`autocomplete' is a verb, not a noun -- so, just as with `Compose',
it should not be the title for a preference panel. `Autocompletion'
or even `Completion' would be better (though the idea of having an
entire panel for autocompletion prefs in the first place seems a bit
naff).
20. The `Address Autocompletion' group box is completely redundant,
since it's not separating the controls inside it from anything else.
21. The checkboxes and option buttons in this panel are indented too
much.
22. Checkboxes are for telling you whether something is on, not whether
something is off. So, don't have a checked checkbox which says `Do
not search in directories'. Instead, have an unchecked checkbox
which says `Search the directories anyway'.
Address Collection
------------------
23. The `Email Address Collection' group box is completely redundant,
since it's not separating the controls inside it from anything else.
24. Most of the checkboxes in this panel are indented too much.
Labels
------
25. This panel should be a separate dialog, it should not be in the
Preferences. Stuff should only be in the Preferences dialog if there
isn't a more convenient and obvious place to put it. In this case
there is a more convenient and obvious place to put it: at the
bottom of the `Message' > `Label' submenu.
26. `Customize the names and colors of message labels.' And what will
happen to me if I don't? :-)
27. The color buttons should be on the left, not the right -- refer to
the Labels tab in the Mac OS Finder Preferences.
28. The `Restore Defaults' button is in a weird place.
Languages
---------
29. This panel isn't about languages, it's about encodings. I suggest
calling it `Encodings' or (if there's room) `Text Encodings'.
30. Checkboxes are for telling you whether something is on, not whether
something is off. So, don't have an unchecked checkbox with the
(extremely wordy and technical) label `_Apply default to all
messages (ignore character coding specified by MIME header)'.
Instead, have a checked checkbox with the label `Allow messages to
use _other encodings'.
Offline & Disk Space
--------------------
31. The option buttons in this panel are indented too much.
32. <grumble>The need for this whole panel could be eliminated if
mail/news had a prominent `Send & Receive' button in its Toolbar
(with just sending and just receiving being secondary functions),
like Outlook does, instead of having a `Get Msg' (I thought MSG was
bad for you?) button in its Toolbar (with sending and receiving
together being a secondary function).</grumble>
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mpt.phrasewise.com/>
Neil
>7. `Note: For this setting to take effect, you will need to exit and
> restart Mail.' is wordy and a bit inaccurate. I suggest `Changes
> take effect when you open a new mail window.'
>
>8. When a changed setting takes effect on a restart or similar, the
> standard method of marking the explanation (on both Windows and Mac
> OS) is with a miniature /!\ icon, not with the text `Note:'.
>
>9. Finally, I would estimate the amount of work required to make this
> pref take effect at the same time as the other prefs, rather than
> when a new mail window was opened, would compare favorably with the
> amount of time required to implement the prefs redesign. :-)
>
Bug 105542. Although my preference would be for a menuitem i.e.
View/Folders/[Above sidebar|Above message|Hidden] (labels subject to
change).
>[/] Check with me if I used the Send keyboard shortcut
>
Shouldn't this be "Warn me if I use the shortcut"?
Matthew Thomas
>
> Matthew Thomas wrote:
>...
> > 9. Finally, I would estimate the amount of work required to make
> > this pref take effect at the same time as the other prefs,
> > rather than when a new mail window was opened, would compare
> > favorably with the amount of time required to implement the
> > prefs redesign. :-)
>
> Bug 105542. Although my preference would be for a menuitem i.e.
> View/Folders/[Above sidebar|Above message|Hidden] (labels subject to
> change).
Yeah, it sucks that this option is in the prefs, a million miles away
from the UI which it refers to. However, I don't think it's frequently
used enough to deserve a main menu item as you suggest. (And it can't be
a submenu item, since it has a submenu itself, and nested submenus are disgusting).
Other options would include:
* having a button embedded in the grippy, for toggling the folder pane
between short and tall modes;
* getting rid of the pref (I don't know of any other mailer where the
developers consider it necessary), always using a tall folder pane,
combined with easier UI for showing and hiding the pane when
necessary for wide messages.
What do you think, Jennifer?
> > [/] Check with me if I used the Send keyboard shortcut
>
> Shouldn't this be "Warn me if I use the shortcut"?
That's how I wrote it at first, before realizing that `warning' the user
about something which they did half a second earlier (well, given
Mozilla's speed, ten seconds earlier) would seem a bit silly.
So perhaps it should be `Check with me [rather than `Warn me'] when
moving folders to the Trash', too. Just as long as it isn't the
mysterious `Confirm'.
Thomas Dodd
Matthew Thomas wrote:
> Other options would include:
> * having a button embedded in the grippy, for toggling the folder pane
> between short and tall modes;
> * getting rid of the pref (I don't know of any other mailer where the
> developers consider it necessary), always using a tall folder pane,
> combined with easier UI for showing and hiding the pane when
> necessary for wide messages.
How easy does it need to be?
Currently, I have a 'grippy' with arrows on it.
I can grab it and change the folder-pane size,
or click it and hide the folder pane, allowing
the other 2 panes to take the whole window.
Or is this a *nix only (GTK+) option?
-Thomas
Neil
>Neil wrote:
>
>>Matthew Thomas wrote:
>>...
>>
>>> 1. Finally, I would estimate the amount of work required to make
>>> this pref take effect at the same time as the other prefs,
>>> rather than when a new mail window was opened, would compare
>>> favorably with the amount of time required to implement the
>>> prefs redesign. :-)
>>>
>>Bug 105542. Although my preference would be for a menuitem i.e. View/Folders/[Above sidebar|Above message|Hidden] (labels subject to change).
>>
>Yeah, it sucks that this option is in the prefs, a million miles away from the UI which it refers to. However, I don't think it's frequently used enough to deserve a main menu item as you suggest.
>
4.x had View/Folders