nex you are right, I am not a graphic designer, I am more into structure and function of interfaces. Usually I work in teams with graphic designers, marketing people and coders, so please excuse my lack of all these abilities.

I assume that you have read the book you recommend, so please give us more specific feedback on this topic than „bad and disgusting“. What should be changed? And I wonder if you can compare Apple software with a html website/application?

Switching comments off is optional. For maximum backward compatibility I did not change it to [ ] disable comments, but we can talk about this.

And thanks for your input on 'editable for subscribers' and 'not editable for contributors' as an illogical selection, I will change this to a group of radio buttons.

‘replaces one control with two’ makes it more visible and a group of radio buttons is also ‘one control’, or?

Nope, I haven't read one of the 'Human Interface Design Guidelines' books and I'm not an expert in this field, so I didn't give much advice there. I just skimmed and bookmarked the Aqua version because this one is finally available on-line, for free, Good Thing. Quite some of the guidelines seem to depend on personal taste, but I do think even those are worth considering. For example, cluttering the interface with unnecessary elements is evil. Drawing a box around a goup of controls and labeling the box is evil, because it breaks the surface up and creates visual ruckus. IIRC, the guidelines say, if you have to label this group, put it under a nice headline. Same goes for the grey lines that seperate subgroups: they do more harm than good, they're not necessary. But there's more to it than I know; if you're really doing interface design work, you should definitely read some good books.

Radio buttons in the "editable for" line would be better, IFF it's made clear that contributors actually are subscribers, too. The current interface does this.

What I don't like about the current form is that it's laid out in a <table>.

It's good that you started the discussion; the new idea about just hiding mostly unused controls by default is great. The three "save" buttons would be nice for people who really often use at least two of then frequently; however, I would have guessed that > 90% of new stories are published to the weblog. That means that almost every time, the currently pre-selected "offline" value is wrong. I would keep the drop-down-list, but either pre-select the weblog option or make it remember the last option chosen (e.g. nice for people who almost always post "to topic").

And concerning the topic selection... there are those combined textfields/drop-down-lists that allow you to either choose a value or enter your own. Are they available in <form>s? This way we'd have one control for the topic selection and it could also be made to remember the last topic.

I broke the rules because most people I watched using antville do not use these options. They do not care or do not understand them. They just write and want to publish to the frontpage. Maybe there is empirical data available about the use of these options?

To show them that these options are not that important and that they do not have to care about them if they do not want, I placed them under the rest. How would you interpret this layout? Maybe there are better ways to communicate this?

Yep, the "editable by" is rarely needed. In my opinion, this could be set as hidden input field, making a default setting (still switchable per site). Sites which do actually use it might change the editor to make it visible.

Puh-leaze! I really want Antville to be newbie and generally user friendly, even for AOLers and other lusers, but that doesn't mean we all have to struggle with a luser interface. When you're typing text you have both hands at your keyboard and having to use the mouse in between to click at those silly buttons would be clumsy.

I would do this wiki style, e.g.

• "[http://uber.nu|link]" -> "link"
• "*bold*" -> "bold"
• "_italics_" -> "italics"

Many users are already used to typing this way, even WinWord supports entering formatting this way for ages. And for others it's easy to learn and consistent with many other applications and anyway the common ASCII representation of strong and emphasized text. * One could extend this * wiki style formatting by * allowing inputting bulleted lists * this way. Hyphens that are surrounded with spaces are almost always meant to be dashes, so we could do that conversion, or allow entering ndashes (–) as -- and mdashes (—) as ---. And stuff.

Actually, I've wanted something like this for a long while already, but haven't said anything yet, because I knew who'd have to implement a first version, and I didn't have the time...

The buttons are evil. They would also require client-side JScript, which I absolutely hate. Every implementation seems to conform to other standards (unlike JVMs, for example, which gehave almost exactly identical) and have more or less severe security holes, and client side J/Java/ECMA Script is primarily sued for misfeatures like unwanted pop-ups/-behinds, data mining and other annoyances, so I have sympathy for every user that turns it off completely and don't want to deprave those of useful features.

I used to have a weblog at Blogger and I didn't use the buttons in the clumsy way in between keystrokes you write about. First I wrote my text and in the end I did the formatting by highlighting the relevant text and pushing the buttons. At the same time I verified and spell-checked my text: Zwei Fliegen mit einer Klappe. Only for the links there is a sequence of mouse movement and keystroke input.

I think one shouldn't hang on too much to principles. An example is database design where the normal form has its limitations and applying it on principle can create rather cumbersome databases.

The JScript thing is the problem of the people who turn this feature off. In that case they obviously can't use the buttons. But why should the others which must be in the majority be penalised?

Your Wiki proposal is interesting but really is for geeks. Which normal user would learn this syntax? Additionally you introduce special sequences of characters standing for html tags which can cause unexpected errors.

An advantage of the design proposal to me seems that the text box is bigger. Right now I find the text box too small and never proof read my posts in the editor. I save the stuff and check the text in the published story. That is a little bit of a nuisance I find.

Me too.

Highlighting text and pushing buttons is also quite clumsy. I have to admit it is much less trouble when combine with proofreading, but post-formatting is often impractical (e.g. when just quickly emphasizing a word) and not everyone proofreads most of his/her postings.

It's true that one shouldn't hang on to principles too much, a compromise could be found. E.g. once you know that the "bold" button wraps something like "<b>foo</foo>" around the selection, you will have no problem with typing that yourself if you can't enable JS because you're posting from a PDA, like I often do. The buttons could be something like a luser-helping-widget that insert vanilla HTML code and can be switched away when they become too annoying.

However, having lots of <strong> and <li> and other tags in your story has a big disadvantage: It degrades readability.

• If you represent
• a list
• like this and emphasis like this and dashes like -- this, everything would be obvious and much less space-consuming than tags. And I don't think this is for geeks. Many users would -- and do -- learn this syntax. Some just like text/plain format in e-mails and Usenet postings, others are secretaries and want to type faster in WinWord, others use a wiki and millions of users for yet another purpose. This format cannot cause unexpected errors when it's correctly implemented (it's necessary to make sure all tags are correctly nested). I rare cases, tags could be inserted where the user didn't want them. Example: A programmer posts a line of Java code without using <code&rt; tags or the wiki equivalent and writes foo(bar--);, which is converted to foo(bar–);. This is not an error and just requires the author to escape the --. SO, I don't see much disadvantages there. The advantage, OTOH, would be that (if the "correct nesting code" also checks manually entered tags) it couldn't happen any longer that someone leaves an <em> tag open by accident and it affects the whole page below that comment.

Changing the size of the text box is another issue entirely; this change takes about 10 seconds. The suggestion to make the default size bigger is very good, though; those text-areas should be bigger.

stimmt

Come on, Alex, this is something we writers should do by ourselves. No need for pushing and pulling these great guys for still more extra coding... Of course you are right, Peter. It is just that I think that the editor can be improved. With a link button we would highlight the text and paste the URL into the box instead of typing fifteen(!) characters for the link tags plus cursor movements plus the URL. That would make life easier for people who run link logs. And if I remember well Kris said somewhere that this wouldn't be a big programming effort. Blogger and Metafilter are using this technique and they have millions of users. And a lot more experience with weblogging than we have. People who don't want to use the buttons don't have to. It is as simple as that. And I do not think that one or three extra buttons would put an overload on the editor. Maybe from the esthetic point of view the beautiful simple editor would suffer a little bit. But sometimes esthetics do not convince me. Especially when they make me lose time for nothing.

I recommend Ghosttyper XML (for Windows, freeware for private use), a neat tool that keeps a lot of typing work away from me. (I really hate to work on a computer where I don't have it installed.)

Use the HTML-Widgets and use <input type="submit" ... > before using custom buttons with custom graphics.

He didn't mean to use custom graphics, whatever he used to draw that prototype just looks like this.

This is the internet and the internet is not the worldspanning network created by president gates nor is it apple net

Would you please be so kind to point out where I suggested anything that would only work under/in Windows/MacOS/IE? I'm not aware of having done something like that; maybe you're just talking out of your... err, never mind.

The Wiki-Style sucks, you already have <strong> and other valid HTML Tags, why build another into it?

This is a valid argument against something else entirely. It is true that inventing new tags for silly reasons sucks, like this special code that's used in some PHP-based discussion fora and looks like [b]this[/b] (I forgot what it's called). The programmer was too lazy to do some intelligent checks on HTML tags (like they do on /. etc.) and just banned them altogether, inventing a silly clone. Yes, this sucks. The "wiki-style text entry" I suggested above, however, is just well readable shorthand for the wonderful HTML tags you mentioned and can exist concurrently with them. It is a well defined bijective map, I don't want to build anything new into it. It is newbie-friendly and no one would be forced to use it. If you want to convince me that this is not Gutes Design, you better come up with some better arguments than "this sucks".

By the way, I did make suggestions on what could savely be weggelassen and how it could be simplified (see above), while you basically said "move the buttons around a bit and then it's perfect".