John,
The fact that we have some disagreements and that there are some
misunderstandings between you and I, and some others on this list, is no
reason for you to be so rude and arrogant. Ignoring your rudeness, your
response indicates that you may not fully grasp everything I've been
trying to express and are still jumping to incorrect conclusions. I'm
going to take a little time to be a little more clear with you. In
return, I would appreciate a little more civility in the future.
Otherwise, I can only hope the list moderators will take appropriate action.
John C. Welch wrote:
On 1/29/10 2:51 PM, "Lachlan Hunt"<[email protected]> wrote:
John, the whole point is to keep the HTML composition features to a
minimum. Provide enough for users to convey the semantics of their
content, but not so much that they can go crazy with wild fonts,
colours, transitions, borders, and other unnecessary bells and whistles.
And CSS wil PREVENT THIS?
With regards to CSS, all I have ever suggested here is a bare minimum of
basic styles provided by the composer, to neaten up the formatting,
compared with the result of otherwise unstyled semantic markup.
To clarify, unstyled markup is where the formatting relies solely on the
styles provided by the recipient's user agent. This is basically 16px
Times New Roman, black text on white background with some basic margins
and padding applied to block level elements, and basic formatting (like
bold, italic, underline and some font size) applied to other elements.
i.e. the result you get if you disable stylesheets on a web page.
To use the terminology from CSS, the basic styles provided by the
composer would be considered "author" styles. However, from the main
user interface of the composer, these styles would not be editable by
the user. (They might be if we provided the option for direct source
code editing for advanced users, or if it were provided by a plugin. But
those scenarios are not pertinent to this discussion, which is focussing
purely on the idea of a basic WYSIWYG editing feature.)
The basic styles provided by the composer would comprise styles for
setting reasonable, legible fonts, styling quotes in replies and
adjusting default heading font sizes. For example, something like
following. (This is a quick example which may not cover everything, but
enough to give you the idea)
body { background: white; color: black; font: medium sans-serif; }
h1, h2, h3 { font-weight: bold; }
h1 { font-size: 1.3em; }
h2 { font-size: 1.2em; }
h3 { font-size: 1.1em; }
/* Blockquote styles to add left borders for quotes in replies. */
blockquote.inreply { border-left: 2px solid blue; margin: 0; padding: 0
0 0 .7em; }
blockquote.inreply blockquote.inreply { border-left-color: grey; }
/* More styles to cover more levels of nested quotes. */
Also note that for better compatibility with different types of MUAs
reading these mails, it may be better to provide these styles with style
attributes on those elements instead. But the exact method for applying
these styles is an implementation detail that can be sorted out later.
The important point I'm making here is how basic the styles are - they
are not overly fancy styles in any way.
Think about the market for just a moment, and think about what such
users really need for composing mail. These are power users who read
and write significant amounts of e-mail. Such users want the ability to
quickly and easily communicate their message, without getting bogged
down in pixel perfect design issues. This is not an app for e-mail
marketers, who want the e-mail themed to match their corporate image and
style guides; or for kids who want to send colourful e-mails to their
friends.
So now you're defining power users to mean "people like you"? Because that's
what I'm seeing. You've just said:
No, that's not what I just said. I said power users are people who read
and write significant amounts of e-mail. The kind of people who deal
with e-mail communication for much of what they do.
Designers can't be power users
Email marketers can't be power users
No, I didn't say that. Designers and E-mail marketers can be power
users of e-mail, and probably are. But when preparing marketing e-mail
— the kind that matches their corporate image and style guides — I can
guarantee that the professionals (at least, ones who are good at it) do
not use WYSIWYG editors to produce their templates. (Once the templates
are written, clients might do so to fill it in with information, but
that's beside the point.) They also do not use regular mail clients for
deploying such marketing campaigns.
I know this because I've done it myself in previous jobs when I was
actively doing web development, and I know what it takes to get it
right. Some of my friends who work with marketing e-mails, such as the
people I know from Campaign Monitor, have done a lot of research on the
markup and styles mail clients support [1]. They hand code their HTML
and CSS too and use specialised tools for deployment. This is most
certainly not the use case that this client is being aimed at.
People under<age> can't be power users.
No, I said kids sending colourful emails to their friends. Of course,
there can be young power users. Age is not relevant here, only the type
of use to be expected. I just said kids as a stereotypical example.
Besides, most kids are not going to be power users of e-mail anyway.
These days, kids use facebook and similar social networking sites to
share photos and videos, and to message each other anyway. This is also
not the use case that this client is being aimed at.
Why not be honest and say if you can't use Emacs for email, you don't count
as a power user.
No, I didn't say, nor mean to imply anything of the sort.
For a power user, the kind of content that they are likely to be
interested in writing is:
* Quotes (including both for replies, and copied and pasted from other
sources)
* Bold and Italic for emphasis
* Links and e-mail addresses
* Bulleted and Numbered lists
* Preformatted text (e.g. code fragments)
* Headings
* Tables
Um, no. Tables are overkill. And then some.
Perhaps. I was hesitant about adding them, but Thunderbird had support
for it and occasionally I do use ASCII-art tables for some purposes.
There are use cases for for tables of data, though, I certainly wouldn't
mind excluding support for tables via WYSIWYG editing, as users can
always attach them in a separate file, or link to them on the web.
* Emoticons
The interpretation of emoticons to images should be up to the recipient.
What, you want to send emoticon images or links to them in the email
Exactly how emoticons are done is not really relevant. But, FWIW, HTML
mail that includes emoticons like :-) and :-P do not get automatically
converted into smiley icons by all recipient mail clients. Thunderbird,
Postbox and Mail.app don't. (I'm not sure if any do, actually).
For plain text, I know Thunderbird and Postbox do, Mail.app doesn't
appear to do so.
I wouldn't say this is an essential feature, and so could probably go
without it, especially if no other clients do. In any case, it's not a
big deal. (But technically speaking, it could be done by including the
relatively small icons embedded within the e-mail like an attachment and
referred to using <img src="cid:...">.)
It's funny how your definition is FAR more complicated than mine. Tables
never, ever, ever occurred to me.
These features are easy to do in plain text, and many users including
myself, find that a whole lot quicker and easier than messing around
with HTML. The aim is to get the message across, not make things look
pretty.
Wait, you say this and TABLES? TABLES?????
Yes, tables for *tabular data*. Not layout tables.
However, I will admit that there are power users who prefer the look and
feel of HTML over the monotony of plain text. But these users are still
more interested in communicating their message than making things look
pretty. The features listed above can be provided with a few very
simple commands. These are the toolbar buttons that I think would be
appropriate for e-mail composition.
Formatting is about enhancing clarity and readability too. It is not some
goofy toy. But CSS??? TABLES?
Precisely. And the amount of CSS I provided aboce, and use cases for
tables are for enhancing clarity. (Though, again, I'm more than happy
not to include support for table editing, as it's a real pain to get right.)
How can you advocate CSS and TABLES in the same email and not have your
computer burst into flame. One of CSS's prime purposes is to make tables
uncessary.
I'm not sure how much web development you've done, if any, nor how much
you know about HTML and CSS, but you seem to be unable to distinguish
between different use cases for tables. Layout tables, used purely for
the visual structure, were indeed largely replaced by CSS. Data tables,
on the other hand, are perfectly legitimate use cases. Do not confuse
the two, nor make wildly inaccurate claims about CSS making tables
unnecessary.
---
* Paragraph (default selection,<p>)
* Headings (3 heading levels should be sufficient,<h1> to<h3>)
* Preformatted text (<pre>)
Yeah. Because just letting people pick a monospace font is so evil.
The precise UI for selecting <pre> (or <code>/<samp>/<tt>, etc.) may
indeed convey to the user the idea of a fixed width/monospace font. It
doesn't matter, I'm not designing the exact UI just yet.
If you select "Fixed Width" from the font menu in Thunderbird or Post
box, you actually get a <tt> element. If you select "Preformatted text"
from the block formatting menu, you get a <pre>. These are reasonable
options, though I don't think they are ideal.
* Block Quotation (<blockquote>)
* Ordered List (<ol> and<li>)
* Unordered List (<ul> and<li>)
* Table
- When editing a tables, the user should be able to specify
header cells and data cells
- Insert/delete rows and columns
- Merge cells
This makes my head explode. So let me get this straight.
Choosing a font: EVIL
Choosing a font size: EVIL
Providing a UI that allows the user to manually specify specific fonts
and sizes, when they don't need to, is unnecessary and bad UI design.
Providing smarter features that lets users enter the text they want to
enter, getting appropriate font sizes and styles for the type of text
they are entering, is better and more convenient for the user. For
example, headings automatically get a slightly larger an bold style;
preformatted/fixed width text gets a monspace font; lists get numbers or
bullets.
TABLES IN EMAIL: ROCK ON BRAH!!!!!
Tables for tabular data, when necessary, is acceptable. Though, I'd be
perfectly happy to leave it out due to the complexites it creates for
plain text conversion, and the ability for them to be attached or linked
to separately.
These commands should be suffient for the vast majority of communication
needs. To get your message across, there is very little reason for
specifying anything else beyond that. It's also very easy to provide a
nice clean and simple default, non-user-configurable [1], stylesheet for
those elements.
How do you propose it not be user configurable? This is after all, open
source code. Undoing that crap will be trivial (PLUGINS!). Want neon pink
backgrouns and flourescent green text? Just use the "blind gramma" plugin.
As I explained above, advanced features like direct source code editing
or plugins are not relevant to the question of what the default UI
should provide.
For the record, your concept here is INFINITELY more complicated and
abusable than anything I have suggested
No, it's not. It's less complicated than what other existing mail
clients provide, especially if we drop the table idea, and doesn't
include any unnecessary font styling.
Most of those can also be easily translated into a plain text
alternative. I realise tables present a little bit of a challenge,
however. (It would be useful to investigate how other mail clients
handle that issue later)
THEY DON'T USE TABLES.
No need to yell.
Not Entourage
Not Mail
Thanks for the information.
Thunderbird does, and that's crazy too. Ye Gods.
I know, that's what I was looking at as I wrote my mail, and where the
idea came from.
[1] http://www.campaignmonitor.com/css/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
_______________________________________________
[email protected] mailing list
List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
