I just saw a post about user preferring web pages over downloading apps. I wonder if this is really true or not?

It might be true in the sense that downloading an app can be seen as cumbersome: browse a marketplace, pick an app, agree to download, wait, wait, wait, wait, click to open, wait, learn how to use the UI. Versus: tap the web browser icon, tap the address bar to change, enter the memorable URL, wait, view a familiar interface.

I think that this is definitely something that requires statistics behind it. Fortunately, it seems Keynote Systems did in fact do just that. Though they also did another survey which said mobile versions of web sites frustrate users too.

This is one of the reasons why I’m definitely building Hiyakoo as the “simple alternative to a complex problem”. It naturally restricts what you can create so that when it comes time to render mobile versions you have a higher chance of: 1) maintaining the same functionality, 2) the formatting still looks great, 3) the load times are reasonable.

I just got an update for the RSpec Book and it comes down as a new ePub file. Just before installing it on my iPad so I can read it in iBooks, I wondered: hm, it’s a new file, I wonder if iTunes will see it as a wholly different book? Well, actually: yes.

The second thought: if it’s a “new” book, will it preserve all of my old bookmarks and highlights? Yikes, the answer is: no!

So of course when I went back to the book and checked the Bookmarks list I got a nice big blank page. Ugh. I think one of the #1 rules of UX/HCI design is to never lose user-input data. I spent a lot of time creating those bookmarks and notes. That’s human effort. There may have been important things in there too. (After all the whole point of making notes is the fact that our capacity to remember things is so limited we have to preserve critical knowledge by making note of it.)

It turns out O’Reilly books has a recent blog entry on this too.

OK, I totally understand that since the source material may have changed that keeping an exact bookmark is pretty much impossible—after all, isn’t that the definition of an “update”, that the material has been altered? Still I think that there are things that we can do to ensure that people’s ePub bookmarks and notes don’t just simply vanish:

1. If you are deleting a book that has user-input bookmarks and notes be sure to confirm that the user is about to destroy this data.
2. ALLOW ME TO EXPORT MY DATA. Even if it becomes completely uncorrelated with the book source at least let me save those notes.
3. When making bookmarks and notes create multiple levels of meta data that note the i) word, ii) paragraph, iii) chapter, and iv) volume. That way if the old location has moved at least you can pop up a message to the user saying something like: The book text has changed. Bookmarks and notes in the [CHAPTER] chapter are still available but no longer reference the same location. At least I still have my notes in the general vicinity of where they were!

I recently saw this linked from a message board and had to share it.

In conversations with people I’ve talked to, I love how there are always two opposing goals: “fill the whole page with my marketing message” and “keep it above the fold”. I’ve been trying to encourage everyone (including myself) to keep things really simple. Sure, sometimes you do need to explain things, but can you tighten it all up so it really only takes a few words?

I definitely understand the idea that businesses need to be able to catch the customer otherwise they’ve lost the customer. And I understand that designers look at the problem holistically. Who is right? Obviously the business owner should know their business the best—we as designers are the hired hands who are just trying to guide them into making better decisions. But perhaps if we ran their type of business we’d also come to similar conclusions that they do?

I think instead that we can settle some of these debates through statistics. I know people don’t like other people monitoring and watching them. It feels uncomfortable. I think of it as the so-called double-edged sword: it can be used to manipulate, but it can also be used to help and optimize.

As a person trying to create and grow a business I want to know what “resonates” with the people that come by my web site. I want to see what are the entry points, what they are reading, what they actually understand within the first few seconds. There’s no point in me making videos or writing explanatory text if no one is going to watch/read it. I think I have a good solution for a problem yet unsolved, and I want to reach a set of target customers that have this problem. If I know how people perceive my service then I can more intelligently communicate my value proposition. And if I have statistics to help me then that’s one more tool I have in my marketing kit.

Yay! What an amazing day! Thank you to Cass Phillips and Diane Loviglio for an awesome FailCon 2010.

Many months ago they asked if I wanted to participate when I was just starting on the Hiyakoo CMS idea and I just “sure, sign me up”. I didn’t know exactly what I’d be presenting or even if I’d have anything to present. Actually, up until last Friday I was pretty skeptical that I’d have working code at all. But things came together and I was actually able to demo a lot of the core tech to all the people that came by the Hiyakoo table. And by the end of the day I was sooooo tired. I talked with dozens of attendees directly for like 11 hours. What a rush, though.

Now a lot of people have seen a very early version of Hiyakoo CMS in an actual demo-able state. It is a versioned content management system with a focus on mobile and SEO. It is intuitive by its direct click-and-edit or click-and-drag manipulation of things on the page, but it’s also technical in that you can get in and tweak properties in a properties panel. It allows for an immediate WYSIWYG preview in multiple formats: computer, tablet, mobile. It lets you compare multiple versions. It offers infinite site style customization, but uses physical restrictions to guide users into lessons that us web designers have learned over the years. It lets both designers and small business owners work collaboratively together.

Hiyakoo CMS isn’t for everyone: it’s just the super fast and easy CMS for busy people who care about good web design that has a little future-proofing built in. I’m trying to finally integrate the best practices of the web into one handy app that is both easily to grok but has super-powerful tech behind it all.

So I’ve been semi hush-hush about the project except to a few people because honestly I’m still trying to prove out theories. Anyone that knows me directly knows that I love doing visual stuff and anything to do with the web. Even with the advent of mobile apps, the web still remains a place for people to congregate en masse—not everybody is stuck inside their Facebook or Twitter microchannels. The web allows us to discover one another because it’s the common platform for the world. But there’s some big big problems a-brewin’ and I’m trying to solve them.

Theory #1: Small business don’t want the hassle of maintaining a web site; designers aren’t necessarily helping. Biz people really just don’t. They don’t want to build it, they don’t want to maintain it. Many have tried it themselves and created sites which are now completely outdated. And it’s too much of a hassle to get it back up to current technology. That’s where web designers come in. Even a quick pass by a designer is better than none. Still, biz owners need to make small changes but sometimes the designers’ modifications to the base site templates are so extensive that it’s not obvious (to the small biz owner) what needs to be changed.

Theory #2: The mobile web is a mystery. It’s a completely foreign language to most small businesses. They can’t grasp the differences required to view a site on mobile—”but it looks great on my laptop computer?!” It is true that iPads and tablets are mobile devices with higher screen resolution but there are still tech considerations that need to be made.

Theory #3: Eyes bigger than stomach. It’s like having an SUV or a sports car. They really like the idea that you can do anything because the system is so powerful and flexible it can. But the reality is that once you get things set up it’s a pain to change it and you don’t end up using all the extra features anyways. Just because you can configure your template any way you want turns out to be too much freedom. Small businesses end up spending days or weeks editing and tweaking before giving up and then just going with a designer. Then we’re right back to Theory #1 where the site can become too hard to maintain.

So. Enter Hiyakoo CMS.

I’m getting back to basics. I think that simpler is really better for a few reasons:

Restrictions on input don’t mean restrictions on creativity. I think of it more as guiding the user to focus their creativity in certain ways. Hiyakoo limits the number of colors, number of fonts, size of the site, width of the navigation bar, and so on. There are physical restrictions everywhere. That does two things:

1) Users don’t spend forever configuring things. They have enough flexibility to get a lot of personalization done, but it limits the time they’ll waste. I come from a rapid-prototyping background where it’s more important to get something up than nothing. It doesn’t have to be perfect! But it has to be good enough.

2) Physically restricting the things you can do means you actually become more inventive. You realize that in order to achieve a better balance of the thing you have they have to work better together. That means you are forced to think about the layouts, the imagery, and the text. You go more towards creating short, quality-packed text than sprawling diatribes that NO ONE EVER READS. Get to your core message and just say it with brevity.

Mobile is the future. Millions of mobile devices have been sold this year that have the capability to access the web. Plus, netbooks are underpowered and have low screen resolutions. What that means to small business owners is that they need to truly consider how their mobile customers get access to their site. Which means that a system (like Hiyakoo CMS) that tries to nudge small businesses into making mobile-compatible sites really is important.

It’s not just enough to have “responsive web design” that uses CSS to change the presentation based on number of pixels available—consider the iPhone Retina Display which has the same resolution as many small laptops yet is physically smaller by magnitudes than a laptop! You really have to be device-aware and have an application making decisions over what is the best presentation for your content. Remember: small business owners DON’T CARE about the mobile versions, so thusly the mobile version should be automatic. Yep, Hiyakoo CMS does that.

Low cost is important, but free sucks. Free sounds nice at first, but a small business owner wants a stable service that will be around for a long time. I just don’t get how a free business model can actually truly work. Good quality engineering and support requires good people, and good people aren’t free. Hiyakoo CMS isn’t free, but it won’t break the bank. Actually, it will be quite modestly priced considering what you’re getting. However, small businesses do want to at least test-drive the solution. So, creating an account and playing around will be free. Even viewing a public version of their site (for a short while) will be free.

There’s so much more to do and say, but for now it seems like Hiyakoo CMS is definitely on the right track.

I have not yet had a chance to play with the new MacBook Air, but I have some thoughts on it.

On the up-side you can now get it with more RAM (4 GB max), a higher screen resolution (1440×900), much more battery life (30 days of standby, really?), an SD card slot (yay!), and two USB ports (big win!), all while still keeping the laptop about as thin as a decently thick magazine. From an engineering standpoint it is pretty amazing. Oh, and the price is actually quite reasonable for the top-end configuration considering what you’re getting.

But of course there are considerations: non-upgradeable parts or a replaceable battery (but most people don’t do this anyways), a 2.13 GHz processor max, and compared to other laptops in similar size/power it is quite a bit more expensive.

As a long-time Air user now I’ve been really thinking and hoping an even more awesome Air would be available at some point. I was fairly surprised to see that a 13″ MacBook Pro was released—that is clearly in the same size/features territory as the Air—so I thought the Air’s days were numbered. Interestingly enough the tag line on the Apple page is “The next generation of MacBooks”. So, is *that* indicating the days of the standard MacBook line now numbered instead? After all, they are the last device to still be made with a plastic casing…

I totally get that the engineering challenge of putting a lot of awesome stuff into a blade-thin device is a stunning technical feat. Seriously, if you have not used an Air you really need to go out and check it out. As a package unto itself, it is a serious portable powerhouse. Claims that this cannot be your primary PC are a bit off the mark: it depends what your needs are.

It is true that the little Air is not quite appropriate for doing video editing, but I will say that it is quite sufficient for most other things. I in fact do use it as my primary computer just because portability rocks. I regularly run Photoshop, Illustrator, Parallels, and other memory/CPU-intensive apps. On a typical day I have at least 1 Adobe application running, Apache w/ Passenger (serving at least 2 Rails apps), TextMate, 2 or 3 web browsers, Adium, Thunderbird, multiple shell windows (with endless scroll buffer enabled), iTunes, and a few other things. Even with 2 GB of RAM the SSD is so darned fast that the disk works like an extra 128 GB of RAM. I have been developing and testing three new websites primarily with this thing. So … when I saw the new Air specs I was … a little disappointed to be honest.

It *really* needs a processor speed bump and 4 GB RAM minimum for the 13″ model. The higher screen resolution is a serious win and the fact that the USB ports are side-facing means you can plug in larger USB devices w/out having to use a hub. But it’s not enough for an upgrade. Oh, and apparently the keyboard isn’t backlit anymore. This release is on the level of an evolutionary step that feels more like a baby step rather than a confident stride forward. (Especially since that new tag line is staring us in the face on the Apple home page.)

A backlit keyboard is very very very handy and I make use of it all of the time. I find myself doing music projects in dimly-lit places and w/out that backlight I would not be able to see what I was doing. I’m hoping the next video processor is good enough to push HD bitrates, but I’m a bit skeptical. And the sideways mic is a bit of a weird choice if you ask me.

I think the key thing to the next Air is going to have to be some kind of wireless integration (3G/4G?). We’re now at a point in history where data plans abound. The point of having a computer isn’t so much so you can do work but you can access websites so you can get your work/communication done. With 3G/4G access we become continuously connected to the world around us. It’s true that we’ll still have to make use of WiFi since it would be astronomically expensive (and slow) to rely on 3G alone. But this future is probably quite close. Either tethering has to be sorted out, city-wide WiFi has to become a reality, or some other kind of in-device antenna needs to get installed.

All this said, if you are in the market for a new laptop and you don’t need a DVD drive and you don’t mind paying a little bit more for a very well-made machine, definitely consider the new 2010 MacBook Air.

It’s nice having a properly-working test system these days. After much fiddling to get Cucumber and RSpec working right, everything seems to be pretty smooth. This translates into much less painful testing, so I feel more compelled to do it often. I’m trying to make it a habit to implement tests whenever possible, but I often don’t make tests drive my development nor do I really shoot for 100% code coverage. Rather, I’ve taken on a different philosophy: tests are only one of your many tools that help you write and maintain a solid app.

As evidenced by other friends’ projects of late, even if you do TDD you can still run into catastrophic errors. It is true that testing definitely helps keep the bug count down, but the tests are usually written from the standpoint that a particular workflow has been followed correctly. What about those other weird cases that we didn’t expect? The app can still fail in spectacular ways.

The way I fight bugs in the code is:

• Code while sober. I don’t just mean it in the literal sense, but when I have to fight through tricky logic or something which definitely has critical functionality I usually turn off as many distractions as possible (i.e. Pandora, TV, IM, phone) and try to ensure my thoughts are focused solely on the task at hand. Today I was fighting a bug which took a while to spot, and if I had been distracted I probably would have missed the absent 5 characters.
• Log everything. My time-tested friend: logging. Because bugs often crop up in context I always log major events, especially where deletions or big data changes occur. This lets me walk back through the logs and try to piece together the circumstances of how the error happened.
• Test high-level stuff. I really don’t care about 100% code coverage because testing only catches things you can think of, not the edge cases. Rather, I care about the big pieces. So if a parent object has tons of child objects, I definitely test on the parent object because I know that if I run particular functions on the parent object and its childrens’ data doesn’t come through properly I know I have a problem in the parent and/or the children. In this case, testing works more like a spotlight on the general location of the error, and that’s fine by me. It may be the case that it’s the interaction with other objects which puts the object I’m testing in a funky state.
• Refactor often. Probably more important than any of the above is the refactoring stage. I have been on enough projects to know that when things go wrong often it’s because some code was copied and so now one of the versions of the code works and the other doesn’t. Refactoring does a couple of good things: 1) continually makes the code smaller and more concise, 2) gives you less things to break. So, when problems happen you have fewer places to hunt down bugs.

David Chelimsky’s The RSpec Book

I’m trying to get better at BDD/TDD but I have to say it is really disheartening when I spend more time just trying to get the Cucumber and RSpec libraries to work.

I *finally* got Cucumber working after weeks of trying then giving up when I was trying to authenticate via the Devise gem. I was trying to follow another example and eventually I found the error buried in the cucumber.log file:

WARNING: Can’t mass-assign these protected attributes: confirmation_token, confirmed_at

Thing is, it’s buried in the middle of a dense pack of other logging messages. Some coloring would have definitely helped. I had been trying to create users:

Given /^I have ones+user "([^"]*)" with password "([^"]*)" and login "([^"]*)"$/ do |email, password, login|
  u = User.new(:email => email,
           :login => login,
           :password => password,
           :password_confirmation => password)
  u.save!
  u.update_attributes(:confirmation_token => nil, :u.confirmed_at => Time.now)
end

(This was adapted from some sample code on the Devise Wiki.)

Well, changing that last bit so the whole method reads

Given /^I have ones+user "([^"]*)" with password "([^"]*)" and login "([^"]*)"$/ do |email, password, login|
  u = User.new(:email => email,
           :login => login,
           :password => password,
           :password_confirmation => password)
  u.save!
  u.confirmation_token = nil
  u.confirmed_at = Time.now
  u.save!
end

Now, that works.

…

Now I’m trying to get RSpec to work and I keep bumping up against the error:

% script/generate rspec
Couldn't find 'rspec' generator

Sheesh. I’ve tried every thing that I can think of. I’ve fiddled with the Bundler Gemfile and still it’s seemingly stuck. And of course it takes forever and a day to update the Gemfile.lock.)

It’s things like this that make it really hard to do the “right thing” when it comes to BDD/TDD. I keep persisting because I know there’s a serious payoff later. But, for a new person to Rails might just give up—and that’s worse.

Update: 12:06 PM

Holy crap. I finally got it working. I happened to try some different search keywords and came across a new conversation on StackOverflow which mentioned:

  config.gem 'rspec', :lib => 'spec'
  config.gem 'rspec-rails', :lib => 'spec/rails'

The key line in the post was:

“because rspec libs are not named as it should …”

WAT. Really? OK, updating my config/environments/test.rb:

config.gem 'rspec', :version => '>= 1.2.9', :lib => 'spec' unless File.directory?(File.join(Rails.root, 'vendor/plugins/rspec'))
config.gem 'rspec-rails', :version => '>= 1.2.9', :lib => 'spec/rails' unless File.directory?(File.join(Rails.root, 'vendor/plugins/rspec-rails'))

Guess what:

% script/generate rspec
      exists  lib/tasks
      create  lib/tasks/rspec.rake
   identical  script/autospec
   identical  script/spec
      create  spec
      create  spec/rcov.opts
      create  spec/spec.opts
      create  spec/spec_helper.rb
%

GAH.

I just came across this: http://www.underconsideration.com/brandnew

Very cool!

So, apparently in the version of Rails I’m using (Rails 2.3.9), the after_initialize callback is supported as a way to initialize ActiveRecord objects after they’ve been initialized (because you cannot override initialize()). However, I had been trying to do:

class SomeTable < ActiveRecord::Base
  after_initialize :some_method
  ...
end

Well, apparently this does not work although the examples seem to point in that direction. There is actually a little note down near the end of the documentation for ActiveRecord::Callbacks which states:

Because after_find and after_initialize are called for each object found and instantiated by a finder, such as Base.find(:all), we’ve had to implement a simple performance constraint (50% more speed on a simple test case). Unlike all the other callbacks, after_find and after_initialize will only be run if an explicit implementation is defined (def after_find). In that case, all of the callback types will be called.

Hence what you really need to do is this:

class SomeTable < ActiveRecord::Base
  ...
  def after_initialize
    # put the code *here*
  end
  ...
end

Oh c’mon.

While reading Drawar I saw a post about the new GAP logo. I mean. What. The. … I’m not even a graphic designer and I can’t figure this one out.

Firstly, gradients: bad. It doesn’t really add anything to the design. In fact, it’s distracting. What is so important about a blue square? I’ve shopped quite a lot at the GAP and I can’t ever really recall them making extensive use of a blue square on any design or sign.

Secondly, why interfering with the “P”? What is the significance of that? P = pricing? Blue square means a chunk missing from pricing?

Thirdly, when the design is shrunk down it becomes highly illegible. As you can see from their web page they go back to a solid blue square too–the gradient actually might have helped readability.

Fourth: Helvetica bold? Really? Not even Helvetica Neue? Or any custom font? I can’t assume that they want to use Helvetica because they’ll use it on the web pages because Windows still has like 90% of the market (if you believe NetMarketShare) and even Windows 7 does not ship with Helvetica. I’m not saying that everything must be Arial, but maybe use Candara instead?

OK, because I can’t stand it, here’s a 5-minute set of comps using Helvetica Bold, a solid blue square-ish thing and in two sizes: large and small for the nav bars.