Archive

Monthly Archives: March 2011

Last year I finally got around to implementing a really good working prototype of an idea I had wanted to do for quite a while: a self-service website building tool. That became Hiyakoo, and I started trying to demo it in the fall. I totally felt (and still do) that there has to be a better way of creating websites for the layperson that doesn’t require a skillset like mine, but I wanted it to be powerful enough that a pro web designer could make sites really sing. Somewhere around December I figured out a few things that I didn’t really want to hear but nonetheless were really important:

Even simple is still too hard.

I tried to make things pretty obvious in a way that once you got a few of the basic mechanics down you could pretty much edit everything with a couple of clicks. I tried to pare down complexity by forcing people to use a single column for layout (which is why I refused to call the site structure a “template”). And I was in the process of installing a help system that would be totally contextual. Yet, this was too complex. There were sliders and panels tucked behind other UI.

The exception is always the rule.

When you tell a small business that they can build their website with ease they begin to do this free association between the word “website” and all the things they can conceive: menus, iPhone app, image gallery, Yelp, shopping cart, special deals and announcements, blogs. More interestingly, even if you start out with a really clean layout it always ends up getting tweaked in a way you (the web designer) didn’t expect. I’m not saying this is bad, I’m just saying that it is very hard for me to sell someone on the idea of simplicity when in the business owner’s mind they might be wanting a special callout of their Groupon or holiday specials. The layout over time just needs to change.

A web designer is still required.

I was really hoping that if I just spent a little time with the business in the beginning that I could get them up and running and they’d be able to edit things from there. That may be true in a bootstrapping sense, but what happens is that questions pop up and it can quickly turn into something much more than just a simple support ticket. Small businesses (in my experience) have so much on their minds that their website is really not top priority. Even for tech-savvy social-media-aware businesses they’d probably end up using Twitter more often than not to post updates to the people that cared—tweaking their main website probably still needs a web designer.

So I’ve been sitting on Hiyakoo for a few months now and just thinking there still must be a way to make it work. In the meantime, a friend is apparently trying to launch a very simple website creator tool too, and about.me just had a big ad campaign. Maybe the time is ripe for a new breed of simple website builders?

Maybe a couple of weeks ago I was still pondering what to do about this code I’ve been sitting on and then I thought: what if I could change the way people thought of what a website is? What if it was just more of a web presence? What if it had a little more flexibility than about.me or flavors.me, but not nearly as much as other CMSes? What could I do to constrain the problem so I wouldn’t get requests to add shopping carts? And this all led me into a long rambling series of thoughts that finally percolated up tonight after a post-strawberry-pie nap…

The upshot is: I have a new plan (based on the old one), a new domain registered, and now I have to just make another prototype.

It is fast coming up on a year since I received the iPad 1 on my doorstep and I thought I would do a little retrospective on how it fits into my daily workflow, or not.

First off, it is an amazing device. It is perfect for reading web pages, watching videos, and playing games. It is spritely, quite portable, and the excellent battery life makes it reliable when you need it. I use it for note-taking and for the quick wireframe sketch. I love that I can demo web sites for clients and access the Internet on the go. However, I find that it has turned to be an information consumption device and not a creation device. (I am writing this post entirely on the iPad to prove a point.)

Typing is the big weakness. It is really hard to beat a keyboard especially with touch typing. The accuracy of touching a flat screen is just not there because of a lack of tactile feedback, and tapping the screen means you occlude the button/key below your finger.

Selecting is also a big time-suck. A mouse or trackpad is a quick and accurate way of telling the computer exactly what you want to highlight, but fingers are very big and clumsy things and you rely on the tablet OS to figure out the most likely touch target. Multiple taps are often required to do common operations like capitalizing words or selecting.

And drawing is just OK. It is hard to get high-fidelity out of any of the software I have tried. Dragging things around still requires additional controls to help nudge things to the right positions after the fact. The screen is small enough that there is no room for a finger-sized toolbar and ample viewing area.

Plus there are the little things like autocorrect correcting words that don’t need correcting, or not correcting ones I really want corrected. Or how this post is using a web page and if I jump to another app and come back often Safari will redraw the screen and I will have lost all of my typing.

So I have taken to carrying my Air around a lot instead. It is truly just the best for work. As much as I would like a different input method other than keyboards and trackpads, they are fast, accurate, well-known ways of getting data into the computer. And in my profession I need accuracy foremost and speed a close second. If I had built-in 3G in the Air I probably would not even need an iPad at all. I still like the iPad’s form factor for reading web pages, but that really is about the best use I have found for it.

So what would it take for me to really use a tablet computer as a work computer? 1) A more accurate method of input like a swing-out keyboard or some kind of key-chording system. 2) Better ways of getting data in/out like having the app data show up in the Mac Finder. 3) External display options to connect it to a monitor. 4) Better multitasking to let me jump between apps or to do 2-up arrangements of running apps. 5) A lot more RAM or a better way for the OS to save state so web pages don’t have to be reloaded constantly.

I just got bit by a rather weird bug. In most programming languages you can do “a modulo b” and get back a number between 0..(b-1). This is wonderful when you have an array of n items and you want to select a number in the range of array indexes 0..(n-1) but you want to use some kind of an incremental counter. For example:

var letters = ['a', 'b', 'c', 'd'];
var idx = 0;
for (i = 0; i < 100; i++) {
  window.console.log(letters[idx % letters.length]);
  idx++;
}

This should print out to the debug console: a b c d a b c d a b c d … and so on. The “% letters.length” keeps the range of integer indexes between 0..3 in this case.

So the cool thing is that instead of incrementing idx you could reverse it:

var letters = ['a', 'b', 'c', 'd'];
var idx = 0;
for (i = 0; i < 100; i++) {
  window.console.log(letters[idx % letters.length]);
  idx--;
}

And we should see: a d c b a d c b a d c b a … and so on.

But not in JavaScript.

Apparently there is a bug where it will constrain idx but it will allow negative numbers! So the idx values in this case will go: 0 -1 -2 -3 0 -1 -2 -3 0 -1 -2 -3 … and so on. What we expected was that it would go: 0 3 2 1 0 3 2 1.

The solution (which also ended up on About.com) is to add your modulo back to the number and do a second modulo. It’s totally inefficient, I know. So in this example:

var letters = ['a', 'b', 'c', 'd'];
var idx = 0;
for (i = 0; i < 100; i++) {
  window.console.log(letters[((idx % letters.length) + letters.length) % letters.length]);
  idx--;
}

or the formula: ((a % b) + b) % b)

Ugh.

So an interesting thing happened the other day. I was reading a popular site that deals with creating web content and I caught myself doing one of the tell-tale things that users do when the fonts on a web page are too small: they lean inward. Now, I know that I’m not exactly in my early 20s anymore and it is true that I do wear glasses almost all of the time now, but my eyesight really isn’t that bad. And I’ve read this site off and on for a while and I don’t remember having to have this lean-in problem before. Then I remembered one thing: I have a new laptop.

Yes, if you’ve read previous posts you know how I used to rave about my old 2008-edition MacBook Air. So light, so powerful, so fast, yada yada. And then I switched up to a 2010 edition at the end of last year. Bigger SSD, higher resolution, dual USB ports, yada yad—wait. Higher resolution? Yes, in fact I now have a 13″ display that has almost 128 dots per inch compared to the old 113 dots per inch. So how much of a difference does that make? Apparently a lot.

For comparison, let me put up this image:

Previously I had a 1280px-wide display that has about 11.26″ horizontal length. Now I have a 1440px display. That means those web sites with tiny fonts just got a heckuva lot tinier. I mean, you would think that 12% smaller might not be a great big deal, but I really do think it does.

I went around the web this morning looking at other examples of font sizing. It seems the smallest comfortable font size for me now is 12px high. The website which has the tiny fonts above works out to about 11px high. But if they just increased it a smidge …

We’re clearly into a time where LCD display technology has gotten so good that we now have displays *AT* (not “approaching”) print resolution. Case in point: Apple’s Retina Display technology gives us 300 ppi. A couple of years ago I had been looking at a Sony ultraportable that was at 220 ppi. We’ve reached the point where small definitely means small.

I don’t exactly know what the solution is here. We could ask browser manufacturers to set their default browser font sizes at a certain ppi. There are some web pages that depend on fonts being only a certain height. Maybe the new tablet era of computing with it’s pinch-zoom mitigates all of this because users just expand the text content until it looks comfortable.

In the meanwhile I’m recommending that anyone making web UIs not use a font smaller than 12px high or 0.90em high.

I’ve been playing around with 3D (or “3-D” if you prefer) transforms in CSS3 to accomplish a kind of “card flipping”. (www.seqmedia.com/experiments/css3_flip) It turns out to be really simple but there’s a couple of gotchas and some general notes:

  • The parent container of the elements you want to transform is the one that should have the perspective: 600; rule.
  • A perspective of 0 does nothing, 10 is ridiculously extreme, 2000 is too subtle, and 500-700 is about right.
  • Safari is the only one that seems to do 3D right now. Firefox supports a -moz-transform rule but it only does rotation, translation, and other 2D things. Chrome doesn’t do 3D either, even though it’s Webkit-based.
  • perspective-origin using percentages didn’t work well for X-axis rotation, but specifying exact pixels worked just fine. (i.e. if you have a 100×200 DIV setting the origin to dead center by -webkit-perspective-origin: 50% 50% didn’t make rotationX work right, but -webkit-perspective-origin: 50px 100px is just fine.
  • -webkit-transform-style: preserve-3d is IMPORTANT. :)

Also, a few helpful links: