Symphonious

A huge amount of the items that flow through my news reader come from Robert Scoble's shared items feed. Most I skip, but there's enough good stuff in there that makes it well worth reading. It keeps me abreast of a much wider range of topics than I would normally read.

The trouble is, Robert doesn't seem to have as low a tolerance level for crap in feeds that I do. Generally I'll unsubscribe from a feed if it has:

1. Ads in it. Particularly if they move in any way, shape or form - generally including just being an image since it flashes up after I've started reading the content due to the download time.
2. Videos embedded regularly (Robert himself is the biggest pain for this). We have this thing called a hyperlink….
3. Partial content.

Fortunately, NetNewsWire support custom stylesheets for displaying feed entries so I can use CSS to fix most of these annoyances. The CSS I use is below - pretty sure I've pulled various bits of it from different places.

/* Hide stupid feedburner ad to this and that links */
img[src^="http://feeds.feedburner.com/~f/"] { display: none !important;}
img[src^="http://feeds.feedburner.com/~a/"] { display: none !important;}
img[src^="http://feeds.feedburner.com/"] { display: none !important;}
a[href*="adclick.php"] { display: none !important;}
a[href*="/~f/"] > img[src^="http://feeds."] { display: none !important;}
a[href*="/~a/"] > img[src^="http://feeds."] { display: none !important;}
.wlWriterSmartContent { display: none !important; }
.feedflare { display: none !important; }
table[cellpadding="6"] td[bgcolor^="#ffffeb"] { display: none !important; }
a[href^="http://dynamic.fmpub.net"] { display: none !important; }
a[href^="http://www.pheedo.com/click.phdo"] { display: none !important; }
/* Get rid of techcrunch video ads. */
div[style^="width:364px"] { display: none !important; }
/* Hide annoying Scoble videos. */
div.snap_preview embed { display: none !important; width: 0 !important; height: 0 !important;}

Thank goodness WebKit support complex CSS selectors…. One note, to get rid of embed tags, you have to set the height and width to 0, not just set display: none which is rather annoying.

Technology is a funny thing - we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other's to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

• They have the power and ability to implement their own code. To build on things and improve them.
• They are probably using your product to save time so the less they have to do the better (ie: we have to make things simple and efficient for our developer users and our end users)
• Since they are trying to save time, they will probably learn the minimum amount possible about your product and do the minimum amount of work.

Not everyone integrator has all three of those attributes - certainly we have a lot of clients that know our APIs backwards and build all kinds of cool stuff, bu the majority are pressed for time and wanting to drop your solution in and move on.

The trouble is, sometimes a simple drop in solution simply can't provide the high standard of end user experience that you'd want. In other words, sometimes you get a trade off between making it really simple for the integrator or really good for the end user. As an example, EditLive! introduced "inline editing" recently which allows the page to load really quickly and display the content in a standard DIV. When the user clicks on the DIV the editor loads there and they can begin editing. Click a different DIV and the editor switches over to there. It turns out to be a really good user experience with just one flaw: how does the user know that they should click to edit and where to do so?

The best possible answer in this case is that the integrator takes a bit of time to fit the functionality into their UI and make it intuitive for users. Depending on the environment the editable section is in changes the way you should indicate the editable section. For example, if the entire page is a form specifically designed for editing, the simplest way to make the user see that the DIV is editable is to apply a border that makes it look like a text area. Users expect to be able to click in a text area and start editing so it becomes a natural reaction. Sometimes you want in context editing so the page should look as much like the final output as possible - perhaps just a tooltip on the DIV is the right answer or maybe a specific cursor (probably combined with some user training since this isn't as natural). Whatever UI is in place it should also fit in with the rest of the site and only the integrator can do that.

Unfortunately, I went off and got married and when I came back they'd shoved a hideous pencil into the product to indicate where user's can click. So when the user hovers over an editable section it gets a blue border and a hideous yellow pencil floats over the content. It has to be the single most jarring part of the user experience anywhere in our products - particularly when blue and yellow aren't part of your site's color scheme. Now I can understand the logic behind adding it, the alternative was to have no visual indication to the user at all which is clearly even worse. We wanted to make it easy for integrators to use the functionality and not force them to implement their own way of indicating editability. There's a problem though - now we've taken ownership of that indicator, if it looks ugly it's our fault or if it isn't intuitive enough, it's our fault. There's very little we can do about it though, the only person who can create the right UI for this is the person who's laid out the rest of the editing page and knows the color scheme and knows how to fit the right UI in (including just writing Click To Edit under the DIV). The integrator is busy though, so they see a UI in place, however terrible it must be, and just go with it. We've managed to make the UI "good enough" for the integrator to ignore, but still terrible for end users. If we'd done nothing the integrator would have felt compelled to do it themselves and would most likely have created a much better UI for their users.

On the plus side, we did add an option to turn off our default rendering so that you can do what's best for your own users. Just call editlive.disableObviousEditableSections(); There's a good example over on LiveWorks!

Bottom line: sometimes you need to be cruel to be kind - if you can't do the job right, make sure you do it badly enough that others will feel compelled to act. Avoid the zone of mediocrity.

PS: I really miss Kathy Sierra's blogging.

I've been keeping an eye on OpenSocial since it's initial annoucement with some interest but also a healthy dose of skepticism. I'm still wondering why anyone would want to support open social. It doesn't give you any integration between systems - all it provides is potential access to the OpenSocial widgets that 3rd party developers make.

Now, if we look at the 3rd party widgets from FaceBook you'd be doing your users a great favor by not supporting OpenSocial. I'm yet to find any FaceBook "application" (I use the term with great disdain) that doesn't do whatever it takes to sign up new users, usability and user experience be damned.

However, if OpenSocial gets support outside social networks it has the possibility of attracting developers who actually care about their users, not just their advertising profits and install count. If that happens, then it may be an advantage to have access to those applications. I suspect a new business model that's not advertising based needs to be discovered first though.

It's with great interest that I see the proposal Brian McCallister sent through to Apache for an open source implementation of OpenSocial called Shindig. If it gets adopted into Apache Roller and Apache JSPWiki (incubating) it could move OpenSocial out of the eyeball obsessed social network scene and into the collaboration market where productivity enhancing applications might start appearing.

Maybe I'm just a spoil sport but I think project code names are the most ridiculous concept. I've never seen a code name help clarify things - they only ever cause confusion. Compare:

Hey Joe, how's the schedule looking for futzbist?

with:

Hey Joe, how's the schedule looking for the next EditLive! release?

The argument is of course that everyone gets to know the project code name so it's a nice shorthand for the project - but for how long do they remember them? How far back can you name Java, Ubuntu, Debian or even OS X releases? Did Puma come before or after Cheetah? What was the Tiger release? And what's in the stray alley cat release?

It mightn't seem important to remember historical project code names, but if you happen to be reading documentation that was written in that era it is. Bug reports don't tend to just disappear after the project you know… The Java bug parade used to be (and sometimes still is) painful to try and extract information from because it refers to Java versions with code names.

Even in the team, it takes time to get a code name off the ground and actually usable - while that's happening you constantly have to add some other moniker to the release to clarify what you mean. Why go through all that pain, why not just decide on it's final, public name up front and stick with it?

Marketing often argues for code names on the basis that then they can tweak the version number right at the end of the release. Why is this so hard to decide ahead of time anyway? You should have a pretty good idea of what features are going in and how important they are before the project gets to the point where it needs a name.

The bottom line is, if you can't think of a single thing that you can anchor down about your release and use as a way of referring to it you've got a serious planning problem. Maybe it's the April release, maybe it's the next release, maybe you know it's time for a major release so it's 7.0 or maybe you know the key functionality you want to add. Refer to your project using meaningful about the project and as quickly as possible get it a final name. For example, right now the engineers are working on the 6.4 release which prior to actually being scheduled was the divs release. I think there's been about 3 attempts to give it a code name and all of them have caused confusion, but the divs release was just so natural and obvious that it worked for everyone immediately.

That said, the other project on the go is known as E2 which is a classic code name - true to form, we spent a year or more trying to work out what it was. The name stuck before we actually worked out what the project was. I'm a little concerned about how long we're going to spend replacing E2 with whatever name we wind up coming up with for it. I don't think it appears anywhere in the code or the product at the moment but there's a massive amount of documentation and discussion that will cement the term E2 in Ephox's corporate lingo for a long time to come.

This rant was triggered by Jeff Atwood.

Is it just me (quite possible) or is the standard JSON validator for JavaScript unable to handle quotes (") in strings? Specifically, shouldn't the JSON below be considered valid?

{"name":"\""}

It throws a parseJSON error when run through the validator but executes perfectly as JavaScript and seems to match the specification for strings in JSON. It's frustrating because even though the data is coming straight from the server so it's as trustworthy as it can get, I still think it's incredibly poor form to execute data without first validating it.

IMMEDIATE UPDATE: Blogging is wonderful - hitting the publish button immediately enlightens you to what's going wrong. Turns out JavaScript interprets \" even if it's in single quotes thus the JSON parser was only seeing " without the ' but executing the JavaScript would still work fine. So it was just me.