The blog that used to be on my blog subdomain is now moving to the main seqmedia.com homepage. Why? It’s about time to start consolidating things.

A while back I had the idea that the seqmedia.com site would be run probably on Rails or some other CMS. But as time has gone on, I’ve come to realize that it’s just too much work to keep the main site updated with the blog and vice versa. Even though they didn’t really change often in terms of style, I’m planning on doing an update that would have required recoding the blog and the main site’s stylesheets and graphics. Rather than copy the styling between the two domains, it just makes more sense to house it under one roof.

In the meanwhile, the main seqmedia.com site is going to be looking a bit more discombobulated than normal as I migrate the data from the blog in and create a new theme in WordPress.

Turns out the Internet was right on this one: if you’re trying to create a big string from little ones it’s faster to << (less-than-less-than operator) on a String than to make an array of Strings and join its elements. Without diving into the Ruby code itself my guess is that strings are linked lists in memory and its end pointer is just moved, whereas making a bunch of array elements means new String objects for each and then having to walk all of the objects to form a new String in the end. (Granted, I’m using Ruby 1.8.7 still!)

Here’s the code:

require 'benchmark'
Benchmark.bm(20) do |x|
  x.report('join') do
    1_000.times do
      a = []
      1_000.times do
        a << 'This is some string stuff'
      end
      a.join
    end
  end
  x.report('<<') do
    1_000.times do
      a = ''
      1_000.times do
        a << 'This is some string stuff'
      end
      a
    end
  end
end

And the result:

          user     system      total      real
join  1.180000   0.390000   1.570000 (1.571057)
<<    1.090000   0.390000   1.480000 (1.491420)

I was playing around with CSS3 and came up with a pretty cool set of realtime transforming square DIVs warped onto a sphere. The result is a spinning ball of awesome.

See the live demo for yourself—please use Safari or Chrome.

Update 6/19:
It just got more awesome.

I’ve been playing more with Rails’ UJS via jQuery and I came across an error that took a while to track down. It turned out to be a content type problem.

Making the form was easy:

And the JavaScript hookup was also easy:

So was the Rails controller:

But Firebug kept showing the error “invalid label”. After much Googling and playing around with things I came to realize that there was one thing that was left out: the content type. Rails was returning the JSON as a string, not as a JSON data type. So a minor tweak to the controller solved everything:

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.

Yes, apparently this is true according to a response on StackOverflow. Let’s say you have a simple form from a model:

  <%= form_for @some_model do |f| %>
   ...
  <% end %>

You might see the following output in the generated HTML:

  <div style="margin:0;padding:0;display:inline">
  <input name="utf8" type="hidden" value="&#x2713;" />
  ...other stuff...
  </div>

Apparently in order to force browsers to submit the form in UTF-8 encoding mode this UTF-8 value (✓) does the trick. If you peer into the code you can see inside the actionpack form_tag_helper.rb that this is called the “snowman_tag”. A little Googling reveals this post on http://railssnowman.info:

What’s with the _utf8/_e/_snowman tag in Rails 3?

The _utf8 input tag forces Internet Explorer to properly respect your form’s character encoding.

Rails uses the accept-charset attribute in your form element to let the server know that it should be able to deal with unicode characters (think of a user searching for café).

But it looks like old snowman value ☃ (☃) has been since replaced with the simple check mark ✓ (✓).

I recently started on a project where I’m doing some pair programming and someone yesterday brought up the Pivotal Git scripts that help modify your Git local.name via a single command: git-pair [person1] [person2]. Then it was the case that another person said that they learned a trick of modifying their shell prompt to show the current local.name so you’d be reminded who you were working with—so you wouldn’t accidentally give attribution to someone you’re not pairing with. This turns out to be really helpful if you’re a freelancer like me who hops around different projects.

Later a nice addition was to show the current branch you’ve checked out. This is critical for me because I never remember and I’ve more than once created a new branch and forgotten to check it out.

And … today I was talking to some more devs and the request came up: “it’d be nice to know if I have modified files in my repo.”

So, I present to you a bunch of commands to add to your .bash_profile that do all of this:

function current_uname {
    uname -a | cut -d' ' -f2 | sed -e 's/..*$//'
}

function current_git_user {
    git config --get user.name
}

function current_git_branch {
    git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* (.*)/; 1/'
}

function git_repo_has_modified_files {
    git status 2> /dev/null | sed -e 's/^#.*modified:.*$/*/' -e '/^#/d' -e '/^[^*]/d' | uniq
}

export PS1='$(current_uname) [$(current_git_user)$(current_git_branch)$(git_repo_has_modified_files)] A w > '
export PS2='  > '

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.

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.

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.