On 1/29/10 7:37 PM, "Lachlan Hunt" <[email protected]> wrote:
> 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. Sorry, you¹ll have to give me few minutes. Your message came in as base 64 (which I¹m beginning to think is possibly the list serve¹s fault) and I have to convert it to HTML, format it so it¹s legible, then return it to plain text, so no one cries. Also, stop lecturing people. It¹s precisely as rude as you think they¹re being. If people are drawing the wrong conclusions from your words, maybe you could state them more clearly the first time. I know I¹m no more happy with the repeat messages than you are, but since the only reason I could disagree with you is misunderstanding of your words, sure, we¹ll play. However, there¹s always the chance that I understand your meaning and disagree, and find some of your ideas rather gobsmacking. > 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. So minimal HTML (that you can actually lock down in the UI) is bad, font selection and sizing are bad for reasons I still don¹t understand, but some how, you¹re going to create an unalterable style sheet that cannot be overridden or modified in an open source application. This may be rude and if it is, too bad, but I don¹t see how you can possibly do that with CSS. > 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. I¹m well aware of what style-sheetless markup is. I was using it waaaay back in the dark ages, when mosaic roamed the earth. What I fail to see, completely is how this is better or more simple than locking the ability to create HTML in the UI to: Font changes and size (I know, eeeeeeeevil) bold/italic/underline/code/strikethrough Left/center/right alignment Ordered/unordered lists In/outdents Text color Proper links That¹s all I see the need for. Others may, and probably will disagree, but that¹s all I see the need for, and quite honestly, unlike a style sheet, you can lock down the HTML composer UI so that¹s all you get. Keeps it simple, allows for better formatting when needed, and a ten year old html engine high on meth could properly render it. There¹s no need to care about CSS support, because you don¹t need it for this. > 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.) Greater complexity, less flexibiity and usability for the user. How is that a win on any level. You¹re not even allowing them to chose a font or a font size without a third party plugin or hacking the application. Oy vey. > 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. */ Wow, that¹s SO much better than the font picker, the font color picker, and twelve or so other buttons in a toolbar. So much more usable. Power users will truly appreciate the utter lack of choice in this. > 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. The important fact that you are missing here is that once you have a stylesheet, in this kind of an application, it is effectively impossible for you to lock it down. If the only options are in the UI, not some hidden text file, it requires some serious plugin mojo to override that. Your way turns into an overcomplicated blinding pink and complex CSS layout with relatively trivial effort. >>> 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. You can¹t have it both ways. You can¹t say that power users are people who use email heavily, and then discount entire segments of that population because it¹s inconvenient to your description. I work for an advertising/marketing firm. Really, they¹re power users. They may have higher email loads than you 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. No, they don¹t, so you trying to use that as a reason to exclude them from the power users group is silly. For email campaigns, they never use an email client, so trying to dictate that they don¹t count because their needs don¹t fit a tool they¹d never use for those tasks anyways is not logical. But for their ³regular² email, they do need to be able to pick the font. For company emails, I have to have my signature in Helvetica. It has to have certain colors for the company name. it has to be a certain size. I have no options in this. So therefore, unless Letters ³happens² to have those in the ³approved HTML featureset² under your idea, I cannot, nor can anyone at my office use Letters, unless we hack the damned thing, or start dicking around with random plugins. That¹s not happening. Nor is it happening at quite a few other companies. I also find your ³they don¹t need pin-point design² argument specious in light of your insistence that all html be set by CSS, since that¹s what CSS was designed to do, or at least one of its goals: allow for pin-point design, down to the pixel, without the need for gobs of table code, or other such idiocies. In other words, it¹s designed to do the thing you say people don¹t need to do in email, whereas basic HTML, the stuff I¹m talking about, doesn¹t need CSS to function and will work in astoundingly crippled html rendering engines on the cheapest phone on the planet, something your technique has a high failure rate in. your way, to really work correctly, requires a fairly modern HTML rendering engine, something that¹s not in the vast majority of non-general purpose computers, and you remove simple options like picking the font and the font size. I have rarely seen someone work so hard to create such artificially narrow definitions of "power user" then deny it to the end of time when it's pointed out to him. > 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. No one but you ever implied this. But even email marketers need to send ³normal² email. Your insistence on overcomplicating this is boggling. >> 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. How cheerfully, wonderfully condescending and dismissive that statement is. (yet I'M the arrogant one.) Evidently, all kids do is send photos and videos. Of lolcats I suppose. I¹ll have to tell my teenaged son, who could give a toss about Facebook, that all the emails he sends to teachers and other students with various class project information, homework, club information and the rest is just not done, and he better get some kitteh pictures up on his facebook right now, or he¹ll lose his kid privileges. I think you need to stop assuming that high school students are the brainless flakes you¹re trying to paint them as to suit your user model. >> 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. What you meant is in your own head. But as far as what you said? Yeah, that¹s what came across. Kids are flakes, email marketers only use mass mailing tools, etc. if you meant something else, use better words. >>> 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 >>> othersources) >>> * 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. That would be the way to go. >>> * 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). You brought them up! Implementations MATTER. Do you think this is bloody MAGIC? You brought up emoticons as a specific aspect of HTML email, rather than random punctuation. Now you say ³oh, well, they aren¹t important.² make up your mind. They¹re either important enough to bring up, or you shouldn¹t have done so. Also, for someone who spent time talking about how all kids need email is for frivolous pictures and videos, emoticons as a line item is a tad contradictory. > 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:...">.) Now you want the application to include emoticon image files, which means lookup tables to match them to punctuation, UI controls to embed them... Yet what I wanted was somehow complicated and going to ruin email. Dude, compared to the pointed stick I was advocating, you¹ve got a friggin¹ stealth fighter going there. >>>> 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 aroundwith >>> 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. How do you propose to restrict this? How do you propose to do this and not have it look broken. This may not have occurred to you, with your web design expertise, but when you put a control called ³tables² in an HTML context, you have created a VERY specific concept in people¹s minds. I don¹t get this, or you. You rail against simple things like font size, and then you come back with Aaaaallllllmost full CSS and aaaallllllmost full tables, and embedded emoticons. I¹m beginning to think that your definition of simple is as Rube Goldberg-ish as your bizarre views on HTML email. >>> 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.) You¹re enhancing clarity by advocating a series of movable walls and extending roofs, with air dams, because a window is just too risky. >> 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 >> unnecessary. > 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. I do a LOT of work with *people*. Hundreds of them every day. I¹ve done so since 1986 in a bizarrely wide range of circumstances, and I¹m telling you that you trying to put a table control in there, and then somehow lock it down to ³data only², (first, wtf is that. Text is data. ³Pride and prejudice is bloody "data²) is going to make people hate that application. People who are not designers and geeks, but are still power users...you know what they use as a data table? EXCEL. NUMBERS. They see a table control in an HTML composer, they are not going to care that they¹re only ³supposed² to put in numbers. They¹re going to see it as a busted table control, and delete the application for being designed by some damned fool who doesn¹t even know what a table is. (and before it starts, yes, I¹ve done web work as well. Database work. About the only platform or task I haven¹t done is Cobol on a mainframe, and thank god for that.) <a bunch of the same silliness snipped, because reformatting this hot buttered ass base64 is actual work, and I have limits.> >> 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. A) you¹re wrong. Look at Entourage¹s html toolbar sometime. Yank the background color, the horizontal bar control on the end, add in a strikethrough. That¹s what I¹m talking about. What you¹re talking about is hideously more complicated than that. B) I¹m beginning to doubt you¹ve examined that many mail clients closely. >>> Most of those can also be easily translated into a plain text alternative. >>> I realize 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. It seems the only way to cut through this insane-assed thing you somehow think is simple. >> Not Entourage >> Not Mail > Thanks for the information. Yes, well, when you have to support a gob of email clients, you tend to learn about them. >> 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. I don't know any other way to say this, but from a complexity viewpoint, what I'm looking for is a paper cube, and you want a klein bottle opening on to a wormhole to the Delta Quadrant. And you STILL, in all this talk about quasi-css and pseudo-tables have YET to explain why allowing access to the font panel in the HTML composer is right up there with eating a baby for breakfast and nuking london. -- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
