Table Alignment

February 2nd, 2009

One of the great challenges of writing an HTML editor is discovering and smoothing over all the weird complexities in HTML. There are just some areas of HTML (and CSS) that are brain-dead stupid and you have to wonder how on earth it ever came to be like that. I suspect most of those brain-dead areas are involved with alignment or tables. This of course means that aligning tables is particularly stupid.

Let’s start with just HTML. There’s an align attribute in HTML which seems nice and straight forward <p align=”right”> will align the the paragraph content to the right. <p align=”center”> will center the paragraph content. Unfortunately this doesn’t hold true for tables.  <table align=”left”> will float the table itself left, allowing the text to wrap around the table. <table align=”right”> will do the same on the right, but <table align=”center”> will just center the table itself, without wrapping text around it.

Now add in CSS – which at least by itself is much more sensible.  <table style=”text-align: center”> has no effect on the table itself, but centers all the contents of the cells. <table style=”float: left”> floats left as does float: right. So far so good, but what if we want to center the table itself? That would be <table style=”margin-left: auto; margin-right: auto;”>  What the?

I’m sure there are good and logical reasons for all these crazy things, but anyone who’s tried to provide an align attribute in a table dialog that’s compliant with both old and new browsers and is intuitive for users has quite significant bald patches because of this.

Ephox EditLive Editor Will Change The World

January 20th, 2009

Pangle on Twitter:

Ephox EditLive Editor will change the world. Well maybe not the world, but it will make WCM content easier to format.

I couldn’t agree more. This is of course in response to the news coming out of Lotusphere that IBM has licensed EditLive! as a standard part of their WCM offering. Ephox has been an IBM business partner for quite a few years now and has built up a lot of relationships with their technical and sales teams as well as selling EditLive! as a third party add-on to a lot of WCM clients. It’s very exciting to see this go up a step and have EditLive! as a standard part of the offering. I don’t have an exact ship date for the OEM version yet, but my understanding is that it will come as an update to Portal 6.1.

So to all the new Ephox clients who are being introduced to EditLive! as part of this agreement – welcome. I really look forward to working with IBM to get you up and running with EditLive! and seeing what it can do to improve you WCM authoring environments and resulting content. I’ve spent the last week putting together a white paper to share the experience we’ve had upgrading WCM deployments to EditLive! and a bunch of best practices for configuring EditLive! to get the most out of it.

To all our existing clients, thanks for all your support so far and  we look forward to continuing to work with you. The OEM agreement includes just the base edition of EditLive! so we’ll continue to ship the Enterprise Edition as an add-on, with some big improvements planned for both it and the base edition.  This isn’t an official source of Ephox news and I want to avoid getting any details wrong so I’ll refrain from giving details, but rest assured that everyone at Ephox is committed to making sure that we keep making all our clients happy – especially those who have supported us in the past.  If you have questions, we’ve got a page giving some information on the OEM agreement and please do contact us if you have any further questions or concerns. The white paper is probably useful for you as well.

To everyone within Ephox, congratulations on making such a fantastic editor, from engineering and product management making sure the product is great, to sales and marketing getting the word out and making enough sales to keep us in business and the admin team for letting everyone else focus on their jobs.

Now let’s get back to work and keep changing the world.

A Scary Thought

November 17th, 2008

While reviewing some screen mockups for EditLive! today, it occurred to me just how limited an environment we’re forced to work in. It turns out that the default, and thus most common, size of a rich text area in IBM WCM is 740×450 (note to Ephoxians, I mistakenly quoted this as 740×360 earlier so we have slightly more vertical space than I thought).  Even in my blog’s editing interface, the editor is 718×600.

That doesn’t sound too bad until you realize that the iPhone has a screen that’s 480×320.

Now an extra couple of hundred pixels width makes a huge difference, but when you look at how much time people spend trying to strip out functions and minimize UI in iPhone apps, it’s scary to think that we aim to pack the functionality of Microsoft Word into that kind of space.

I think the only reason we manage it is by providing real drop down menus, whereas most in-browser editors just try to cram everything on to the toolbar. At least I know why UI design for EditLive! is such a challenge…

Ephox Meme: 5 Favorite Features

November 12th, 2008

The Ephox bloggers have been way too quiet lately (myself included) so I thought I’d start an Ephox meme. What’s your 5 favorite features of any of Ephox’s products?  They might be built in or plugins that we’ve developed, maybe even features of our internal systems that make your life easier, but preferably something that our clients could get hold of (teasing people just isn’t nice).

Here’s my list:

  1. Built-in Image Editor. Particularly being able to resize an image and add rounded corners and drop shadow.
  2. Pop out window mode. More editing space is always good.
  3. Automatically detecting URLs on the clipboard and using them as the default value in the hyperlink dialog.
  4. Styles menu. Not that I use it on this blog, but having access to classes in the site style sheet make it so easy  to apply some really nice formatting with just a couple of clicks.  The styles package prototype we use internally a lot is particularly useful for this.
  5. The extensible APIs. It’s so nice to be able to quickly add support for footnotes, a shiny button generator or whatever I happen to want this week. I wish more clients used this functionality to make life easier for their users – even if it was just by providing a handful of simple templates they could insert.

I tag Suneth, Damien and Brett

One Line Toolbar

October 16th, 2008

I was going to write a post around accessibility and WCAG 2.0 but got annoyed once again about the EditLive! toolbar taking up two lines instead of one.  I’d already removed a whole bunch of stuff from it but it was still wrapping around by a few buttons.

It occurred to me that there are a range of functions that I had on the toolbar because I use them frequently, but that aren’t actually required because I always use the keyboard shortcut. In particular, I have no need for cut, copy, paste, undo or redo because without exception I use keyboard shortcuts. I could probably apply the same logic to strong, em and insert hyperlink as well but my toolbar fits on one line with them so they may as well stay.

Here’s what it looks like:

  • Styles
  • Insert hyperlink
  • Insert image
  • Strong
  • Emphasis
  • Insert unordered list
  • Insert ordered list
  • Decrease indent (actually I always use shift-tab anyway)
  • Increase indent (ditto but for tab)
  • Insert table (useful on the toolbar so you can just drag out the size instead of going through a dialog)
  • Pop out into a new window – great for getting that extra space you need to see what you’re doing.

Everything else is still available in the menus if I need it, but the toolbar is reserved for really quick access to common stuff – just like it should be.

This leads me to Sutton’s first law of editors:

The perceived value of an editor for purchases changes in proportion to the number of buttons on the toolbar, whereas the actual value of an editor for authors changes in inverse proportion to the number of buttons on the toolbar.

Thus, editor vendors should add as many buttons to the toolbar as possible to show off the functionality and nearly all of these should be removed before you actually put it into production. Note however that this is about toolbar buttons, not features – I use an awful lot more functionality than what is on the toolbar but not commonly enough to need to move it out of the menus. This minimal toolbar simply wouldn’t work with an editor that didn’t also have a menu bar.

Note to self: I really must add a good style for highlighting important sections like the law above.

Further note to self: Also need a good style for these notes to self.

Note to engineers: I love how easy it is to add drop shadows with the inline image editor. Finally even lazy people like me can join the Web 2.0 drop shadow revolution! Fantastic work.