Monthly Archives: November 2010

Web programming in a padded room

Posted on by
Reply

One of the big issues I’ve been trying to work around is how to give people the freedom to be creative but to save them from breaking their site. I had a few moments of downtime and I started thinking: what if users could in fact enter any HTML and CSS they wanted. But. If I find out they’ve entered invalid HTML I find a way to flag the errors and help them correct the problems.

(Invalid HTML would not only harm their site but also the site editor since it is a fancy web page that shows a realtime rendering of the users’ sites. Illegal HTML could break the editor the next time they reload the page.)

So the solution that I just threw into the editor: any user-entered HTML is passed through the Nokogiri parser and if there’s issues then the entire text is HTML-escaped. That way, failing to terminate paired tags, certain spelling mistakes, and missing angle brackets should not cause issues. Of course there’s still issues of broken JavaScript or invalid inline CSS, but that hopefully should not happen too often. It’s like giving users a harmless play area where mistakes don’t cause disasters.

A realization that happened last week was that most site owners will not be doing the data entry for their sites, even if they are creative professionals. It turns out that people are just too busy. Which is why us web designers continue to have jobs. And especially now when small businesses are scrambling to keep their business going they’d rather have a web pro do their site. Because of this the chances of them touching HTML are slim.

However.

They need the ability to embed a YouTube video or insert a Facebook button or some other tracking code.

I thought about blocking this behavior entirely because it does in fact lead to some issues around repackaging the content in a mobile context, but perhaps a more intelligent source parser can just rewrite their video embed code on the fly. In other words, let’s wait until this actually does become a problem. It is also the case that if the web site does turn out to have problems, small biz owners will call their web professional back anyways. Thank goodness for the version-controlled underpinnings of the system.

“Dissecting Android’s openness” @TUAW

Posted on by
Reply

Richard Gaywood’s post on “Dissecting Android’s openness” I find to be a pretty well thought-out argument for why the open/closed argument is mostly marketing speak, but that Apple leans more towards closed while Android is more towards open. In the end we have to consider the users: is it more important for an iPhone to be instantly recognizable and easily operable by any iPhone user around the world? That the icons and gestures are all familiar? That the experience of Apple is much like the experience of McDonalds and Starbucks: consistent?

The good thing about consistency is that it plays back into the easy-things post: once you acquire knowledge about how to use something you gain confidence and then the device becomes “easy” because you’ve seen it many times before. It is effortless because it is familiar. And thus, so long as you only have to learn a minute trick (like creating app groups) the device continues to be simple and enjoyable. My current experience with Android handsets is that every time I pick one up and use it I get confused as to how things are organized and there’s lots of things that are non-obvious—all of my friends’ Android phones are slightly different. Conversely, every time I use a friend’s iPhone I instantly know where everything is.

Thinking a little more about the UX of iPhones/iPads/Lion, so long as we think Apple is making good UI/UX decisions then we’ll probably continue to enjoy Apple devices. However, if Apple does something we consider to be so irksome that it encumbers our use of the device so much that we wish to change it, then we’d probably start moving towards Android. Because you can get to the source you can make changes. But then again, even if you make the changes your handset might be different than your friend’s. Even if Google likes your change, the handset manufacturers might need to incorporate that change. And now you’re right back where we were before the spate of smartphones: customers are bottlenecked waiting on their carriers to do the update.

Doing a quick search on Froyo (Android 2.2), it was released by Google on May 20th, 2010, but even as of today November 8 there are handsets still waiting to use it. Of course, an iPhone user could choose not to upgrade their phone and then they’d be running the older OS indefinitely, but at least it’s the user’s choice. In this case, even if the users want to they can’t. So when the latest and greatest UI/UX improvements come out in the next Android version, user confusion might abound: will my handset be capable of running it? Will my carrier let me? What about the mods I installed? Will my apps work? The burden of ensuring the user’s device shifts from the companies to the users; in Apple’s case Apple maintains the brunt of the load to make sure the OS works across at least 3 generations of devices.

I’m all for innovation. I think the world is also big enough for competing philosophies on how innovation should be carried out. I’m glad that both the Apple-controlled way and the Android-multivariate/DIY ways exist.

Trial and error

Posted on by
Reply

Ever have a really good idea that—once you build it—gives you a new perspective? That’s what’s happening with the Hiyakoo CMS right now. After FailCon I’ve had a bunch of follow-up conversations and they revealed some much-desired functionality. Incorporating those things and also trying to really make the site editor interface solid has revealed some new ideas.

As the WYSIWYG portion gets built out I’ve come to find that there are certain pieces of user interaction that just aren’t smooth enough. It requires a zig-zag pattern of the mouse to move from one area to another and back again—that won’t do. I’m a big fan of contextual editing, and that also means that if the user is looking in one area of the screen that the cause-effect of their actions should also be relatively in that viewing space. To that end, some things which I thought were going to work just really don’t.

I was asked just today even “when is it going to be ready?” The short answer is: when the core functionality and UX are solid enough. Of course, balancing out the main features from nice-to-have is always a difficult task for an unreleased product, but I think I’ve got a pretty good sense of where the baseline requirements are now. Then again, once it’s in the hands of real users new things always crop up.