Joyent seek to renege on lifetime hosting deal

Back in 2006 I invested $499 in a Lifetime ‘Mixed Grill’ hosting package from Joyent. The company was pretty young then and they used a series of lifetime package deals to raise capital. The deal on offer was very clear. You can still see the original product page on web.archive.org. It says: “How long is it good for? As long as we exist”. Joyent still exist, of course, but this morning I had an email from them saying that this hosting product was coming to its ‘end of life’ and my hosting service will be shut down on 31st October.

What?!

Back in 2006 paying $500 for a lifetime account with a new startup hosting company was a risky thing to do. I didn’t know if the company would exist in a couple of years time. But that’s the way investment works. You take some risk in order to get some reward. And with this particular type of investment, our return was to be a lifetime hosting service.

Sorry, Joyent, just because your company is bigger now, and (presumably) doing well, doesn’t mean you can suddenly break a clear deal with your early customers. There are quite a few of us. Hopefully Joyent can be made to see sense. I find this pretty incredible to be honest, and it’s depressing to see a company that seemed to start out with really good values sink to such cynical behaviour.

Illustrator ‘save for web’ anti-aliasing problems

Update: it seems I was completely wrong about this and Illustrator does have a special anti-aliasing option for type optimisation. The option is buried in a slightly strange place in the ‘Save for web’ dialogue, under ‘Image size’. Select ‘Type optimized’ instead of ‘Art optimized’. Thanks to Monika Gause for telling me about this! Incidentally, another way to achieve this would be to use Effects > Rasterize and again set the option for ‘Type Optimized (Hinting)’.

Adobe Illustrator is a great tool, but it seems to have some real problems rendering anti-aliased text when using the ‘Save for web’ function. Text from very thin fonts is a particular problem. In these cases, the text looks fine while you are working on the file – I usually have the anti-aliasing set to ‘Sharp’ and it does look crisp and clear. However, as soon as you go to ‘save for web’ the results are awful.

So here is what I see while working on some text (this is set in Museo 100). This image comes directly from a screenshot in Mac OSX:

And here is what Illustrator gives me when I select “Save for web & devices”:

The text is rendered very poorly.

As an experiment I created the same text in Photoshop and did “Save for web & devices” and it has no problems at all:

It’s a really annoying bug, and it’s been around since at least version CS4, as we can see from this post on the Adobe help forums.

I use Illustrator for nearly all my web work – it’s a great tool and very quick to work in, and ‘pixel preview’ mode and ‘snap to pixel’ mean you can produce precise graphics for the web. However, it looks I might have to start using Photoshop more. Disappointing.

A really simple font resizer using JQuery

Sometimes it’s useful to have links or buttons to increase the font size on a website. Even though browsers have built-in functions to resize content, not all users are aware of this, or can easily remember how to increase the text size.

The general mechanism for resizing text is to have one link to increase the font size and one to reduce it. However, it can get tricky for the user to keep track of what the original size was, so sometimes people include a ‘reset font size’ button.

At this point the UI is starting to get a tiny bit complicated, so I was looking for a way to create a dead-simple widget with just 2 options – small font or big font. Keep it simple.

I’m sure someone has done this before, but I couldn’t find a script on Google that did everything I wanted, including changing the styling of the currently selected font size to make it obvious, as well as a cookie to make the size selection persistent across pages in the site. So I hacked around with a couple of other scripts I found and created a solution using JQuery.

The advantages of this solution are:

  • The UI is really clear and simple (you could make buttons instead of links if you like)
  • A separate class is toggled for the currently selected size
  • The resize links are only displayed if the user has javascript enabled
  • The font size selection is persistent across pages
  • The resize affects the font-size as set on the HTML body element. So all text that you want to be resized needs to be sized in percentages or ems. If there are some elements you don’t want to be affected by the resizing, you can specify their size separately in pixels.
  • Unobtrusive Javascript

A few notes:

  • By loading the JQuery library from Google’s servers, it’s likely that the code will already be cached, thus saving download time
  • You need to include the JQuery Cookie plugin separately
  • Font sizes for LARGE and SMALL need to be set in the JS file
  • The links need to be set to display: none within your stylesheet so they are hidden by default. They are then revealed for JS-capable browsers only

I got the basic idea for how to approach this using JQuery from a post on ShopDev.

Using metaphors in web design

Graphic design is all about communication, and on a website we usually want to communicate something about a service or product or organisation. We probably want to tell people about its benefits and strengths. Of course one way to do this is to tell people directly – to write down various facts about your service or product. Another way is to help shape a viewer’s emotional response to a web page by the way it is styled – particular uses of colour, contrast and typography are used to create a particular ‘look and feel’. This is communication working on a more subtle and ‘emotional’ level. A third method we can use is to sort of combine the two and create a metaphor that communicates the essence of your message in a non-literal way. It’s something that we see around us in advertising all the time.

To give an example, at ILRT we were recently working on a new website for the Worldwide Universities Network, an alliance of 18 universities across the globe that join together to encourage interdisciplinary research. The main audience for the site are academic researchers who may be interested in starting a new collaborative research relationship with another group in another WUN university. In this case it was useful to distill out a key message for that audience – one that summarised the benefits offered by WUN – and marry that to an image that illustrates that message metaphorically:

wun-homepage

The benefit of this type of design is that it allows you to communicate your message in a visual way. Images are more instantly accessible than words and require less effort to process. In this case the distant expanse of horizon ties in with the idea of looking at the future and meshes with the tag line. Tag lines can often be used to clarify the metaphor you are making and anchor a non-literal image to the actual subject of the design.

Here’s a homepage for a software company:

stand-out

In this case we determined that the immediate appeal of the company’s software products was to help it’s clients stand out in the market place. So I set about trying to capture that concept in a non-literal way. In a literal sense, of course, fruit has very little to do with software. But the image implies the concept of ‘standing out from the crowd’ or ‘being special’ which is what we wanted to communicate in this case. The fruit also has a secondary connotation – that of being tasty. Images of delicious food work on our senses in a more immediate way than software usually does.

As a web designer, using conceptual or non-literal design solutions can be liberating. You know what it’s like, you’ve just landed a new job to design a website for a firm of accountants. The obvious choice is to use images of people in suits reading documents, perhaps a close-up of a spreadsheet or a calculator. Not the most inspiring stuff to work with. But perhaps we can look at it from another angle – what kind of function does a good accountant really perform in the life of a business? He is a necessary part of helping a company grow and flourish, helps to keep things in order. Something like a gardener perhaps? You could then shoot off to your favourite stock photo site and start looking at images of tended gardens or beautiful trees growing.

Setting up a local server on OS X Leopard

This week I’ve spent quite a few hours trying to set up a local development environment on my new Mac. Although I’ve used the built in version of Apache 2, much of the other software that comes pre-installed with OS X is not ideal and needs to be replaced or tweaked. It is also not a bad idea to have your server software in /usr/local to avoid it being potentially broken by system updates. This is a brief record of the steps necessary to create a solid server setup that suits me, mainly for running WordPress sites (PHP and MySQL) and Ruby on Rails. It’s really more of a record for myself if I ever have to do it again – although no doubt next time it will be on Snow Leopard and everything will be slightly different!

  1. We’ve going to use the built-in version of the Apache web server. To start/stop the web server, go to System Preferences in OS X and select Sharing > Web Sharing.
  2. Move the Apache document root to a more convenient location (my personal ‘Sites’ directory): open /etc/apache2/httpd.conf and change the ‘DocumentRoot’ variable in 2 places (note: the PHP module should be left commented out, as it is by default). Next enable .htaccess by editing /etc/apache2/users/<username>/<username>.conf and specifying Options All and AllowOverride All. Restart Apache.
  3. Download and install a more recent version of PHP with more capability than the standard Apple one (GD library, Mcrypt, etc). This installs PHP into the directory /usr/local/php5.
  4. Download and install a version of MySQL server that correlates with that version of PHP (so the PHP MySQL library matches). MySQL is installed into /usr/local/mysql-5.0.77-osx10.5-x86 with a symbolic link from /usr/local/mysql.
  5. Create or edit ~/.bash_login and add this line to the end: export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH". This makes it more convenient to interact with MySQL from the command line, as well as pointing our system to our custom software installations in /usr/local.
  6. To start MySQL from the command line type sudo mysqld_safe (To stop MySQL type mysqladmin -u root -p shutdown)
  7. Set password for MySQL root user: mysqladmin  -u root -p 'mypassword' (Note that the MySQL user is different from the Unix user that the MySQL is running under – usually _mysql).
  8. To check current users in MySQL, use: SELECT Host, User, Password FROM mysql.user;. Set passwords for all as necessary. Alternatively, to limit access to your personal machine only, create the file /etc/my.cnf as detailed on this page (‘A Note About Security’).
  9. Set passwords for other users/hosts as required – see instructions half way down this page. Create an ‘admin’ user for MySQL so we’re not using root in the various config files etc. Will need to grant privileges.
  10. Download and install PHPMyAdmin. Unzip and rename directory, then place in web document root. Make a file called config.inc.php to put in your blowfish password (any random phrase will do). You can copy libraries/config.default.php if you like.
  11. Make sure you’ve installed Xcode from the OSX install disk.
  12. Add in MySQL C bindings for Ruby, to make Rails faster – instructions near the bottom of this page (you will need to have Xcode Tools installed in OS X to do this – use your OS X installation disk if needed)
  13. Follow the instructions on HiveLogic for installing Ruby and Ruby on Rails into /usr/local.

Correct use of HTML headings on a homepage

There’s been quite a lot of debate about the correct use of HTML headings (H1, H2, H3, etc) to define a document structure. WCAG 2.0 says that we should create a correctly nested structure of headings, not least to help users with screen readers browse through content on a page. Conventional standards-aware wisdom says that each page should have a single H1, followed by H2s, H3s, etc. This is fine for a web page that is structured like a Word document – we have an overall heading, and then sub-headings. But what about a homepage that consists of some branding, navigation, and then a grid of ‘teasers’ for deeper content on the site? This is a different kind of page structure, and arguably not one that HTML was designed for, so there’s going to be some compromise.

  1. There’s a good case for saying that on the hompage (only) the logo or name of the site should be marked up as H1. I don’t think this should be applied as a general rule on other ‘content pages’ because this is a waste of the H1 function both for screen readers and for search engine ranking. But we could make an exception for the homepage. It sort of makes sense. But then you have a slightly fussy situation where the HTML and CSS for your logo is different for the homepage than for all other pages.
  2. Another alternative would be to allow multiple H1s on the page and markup all the teaser headings as H1. This feels instinctively wrong to me, because I think an H1 should define the overall, main content for a page. It probably also dilutes the effectiveness of the headings in search engines, and isn’t going to help screen readers if they’re expecting a single H1.
  3. Alternatively, we could choose to miss out the H1 tag for the homepage. This makes sense from the perspective of the information architecture for the site. Afterall, those teaser headings are H1s on the content pages they link to, but shouldn’t be H1s on the index page. In terms of screen readers: if an H1 is not found, presumably a decent screen reader will try jumping to H2. It may not be totally ‘correct’ but I doubt this is going to trip someone up in practice? On the other hand, you are wasting the power of that H1 for search engine ranking.
  4. I suppose a further option is to put in a ‘phantom H1′ and then hide it with CSS. But that also feels a bit messy.

So anyway, I’m leaning towards options 3 at the moment in cases where an H1 tag doesn’t really ‘make sense’.

Designing Web Apps Workshop with Ryan Singer

Earlier this week I went to Ryan Singer’s workshop on Designing Web Application User Interfaces. Ryan is a designer at 37 Signals, the company behind the massively popular Basecamp project management software (which I use myself all the time) and several other useful web apps. Here are some thoughts on the workshop.

Clean UI Design

Ryan has a real ability to simplify and re-structure a UI so that it communicates as clearly and effectively as possible. The basics of his approach are available in a paper on UI Design Patterns he wrote a few years ago. He argues that most of the important work in UI design actually consists of writing copy, rather than creating graphics or layouts. Cleanly written labels and headings are the key to improving ‘scanability’ and therefore a clear UI. Sort of reminds me of Oliver Reichenstein’s observation that 95% of web design is typography. And seeing Ryan in action working on a UI was definitely useful for me, even though I already know much of the ‘theory’ and have done it many times myself. It gave me a bit of a fresh perspective.

Designing for Yourself

37 Signals seem to follow a sort ‘expert-led’ design philosophy. They don’t really do user research. And I suspect they can get away with this partly because they are designing for themselves and for people just like them – other web geeks. It’s a pretty liberating way to work and it’s clear that they’re good at what they do, but I wonder if they would be quite so successful if they were designing web apps a completely different demographic. Basecamp is great but I wonder sometimes if non-geeks really ‘get it’. For example, at work when we ask non-techy clients to use it, they often seem to prefer email and telephone calls.

I was also a little bit shocked by Ryan’s admission that he ‘doesn’t really think about accessibility’. Perhaps that also says something about the target audience for their apps. But it wasn’t an entirely helpful stance to take in a workshop teaching a general audience in the UK about web app design.

Workflow

Ryan told us quite a lot about how the team works at 37 Signals. One clear advantage of using an MVC framework like Rails is that, because of the strict separation of markup from program logic, the designer can continue to ‘own’ the front-end CSS and HTML right through the life-cycle of the product. This sounds really ideal and I’m sure it makes a huge difference to the final quality of the interface. It can be really frustrating as a designer to hand over a carefully constructed HTML template, only to see it gradually erroded and degraded as it is integrated into the back-end and new functionality added.

Another key aspect of the 37 Signals workflow is the practice of designing directly in HTML. I think this kind of an interesting idea and has some upsides. Clearly it can work well and it results in designs that work with, rather than fight against, the medium of implementation. But it occurs to me that all of 37 Signals’ applications are very much purely functional ‘tools’. For some web apps imagery and ‘visual design’ are more important and in those cases where you need ‘more graphic design’, working directly in HTML is going to be very inefficient.

Conclusion

Overall it was valuable to see Ryan in action and to get first-hand exposure to the way he thinks about and analyses UI problems. I’ve already found myself thinking in a slightly different way when designing a complex page. It has also led to some useful discussions about how to allow designers to keep ‘ownership’ of HTML markup right through the life-cycle of a web application. I think that is something 37 Signals have got exactly right. I think Ryan could make his workshops even better by doing a bit of extra research about the general environments people have to work in today, and considering some of the issues we face. For example, accessibility is quite an important issue and can’t just be brushed aside, and designing directly in HTML is not going to work for every kind of web application.

Customised search scope in WordPress

Sometimes in a WordPress site you might want to have the option to search within different types of content. For example, if one category contains blog posts and another one contains white papers, you might want to allow people to restrict their search query to blog posts only. Here is a slightly hacky way to achieve this.

Create a specific template for displaying search results – search.php. Then, by placing an extra field in your search forms, you can check for this value within search.php and display or hide certain categories depending on what you detect.

So for example on your homepage you might have a search form with a field like this:

<label>Restrict search to blog: <input name="scope" type="radio" value="blog" /></label>

Then within search.php you would pick up that value like this:

<?php $scope = $_GET['scope']; ?>

And then use that to skip certain categories within the loop:

<?php while (have_posts()) : the_post(); ?>
//Skip this result if it's out of scope:
<?php if($scope == 'blog' && !in_category(1)) continue; ?>
....

Of course you can make this more complex by setting up multiple scopes and including more categories in each.