zach waugh
  • Blog
  • Projects
  • About
zachwaugh

System Status Pages

February 14, 2010 - 0 Comments - design user interface

I’ve been really digging the status pages for various web apps/services lately. As these services grow larger, and we grow more dependent on them, it’s critical that we know how they’re operating. They’re typically one page sites with a single purpose - to report the status of the system. Usually, that is broken down into current status and recent status history, in which the primary focus should be the current status, and the history secondary. Often, they’re completely separate from the rest of the site/service, so they can have their own identity as well. I love to see the results that come from those types of minimal requirements.

Github status page From what I’ve found so far, my favorite is the recently launched Github status page. It’s a nice, clean design and the large, color coded header immediately conveys the current system status. The recent history is listed below, and makes it easy to scan for any recent issues. Also, it’s hosted on Heroku, so it’s external from their site, which is a necessary ingredient for it to be of use to anyone. Bonus points for auto-updating the status page via AJAX.

OpenDNS status page OpenDNS is pretty good as well. I like the big green button for “System is currently online”. It would be much better though if they just swapped the Current Status and top section. My eye is drawn to the total activity chart which is not really that important. They also provide an IP address link for the status page since if their service is down, and you use them, you couldn’t resolve the site’s domain anyway.

Google AppEngine status page Google’s app engine status page is not bad, but like most Google creations, a bit heavy on data and light on design. At least you can easily see the current status. I like the use of friendly words like Now/Today/Yesterday so I don’t have to think about what today’s date is. I would prefer if the table went from most recent to least recent though.

I’ve posted some screenshots of other ones I’ve found in this flickr set. Let me know if you know of any other good ones, and I’ll add them.

Some thoughts on the Apple iPad

January 27, 2010 - 0 Comments - ipad apple

After many months of rumors and speculation, Apple finally unveiled the iPad. Almost all the questions have now been answered, but a lot of people are asking, what do I use it for? If I have an iPhone and a Macbook Pro, where does this fit in? I can’t answer that for everyone, but I can tell you why I’m planning on getting one.

I’ve been thinking about this device for a while, and my line of thought has been, if this is a big iPhone/iPod Touch, what apps do I currently use on my iPhone that would benefit from the larger screen? Of all the apps, only Safari, Reeder, Tweetie, and Instapaper really stick out. And that’s just because those are text-heavy apps used for reading, and that is the iPhone’s weakpoint. Take those apps, and add in the Kindle app and iBooks, and I’m already sold. Even just as a glorified web browser, feed reader, e-book reader, it’s enough for me to buy one.

The problem is I follow a lot of feeds, and send a lot of stuff to Instapaper throughout the day, but I don’t have a good way to consume it. I don’t want to sit at my desk and read it. I don’t want to sit with my scorching Macbook Pro on my lap that after 4 years, only gets about 45min of battery life. I don’t want to unplug it from my external monitor/keyboard and move the one power adapter I have. So the only option left is to use my iPhone, which works, but is far from ideal. The iPad fits in perfectly here: lightweight, long battery life, instant on, beautiful screen, and plenty of apps to download and present content in an ideal way.

So for me, the iPad is first and foremost, a reader. I’m sure I’ll watch movies on it when I’m traveling, play some games, and use the other apps, but that will be secondary. However, I do think that some real interesting ideas come not from thinking about what iPhone apps would be useful larger, but what desktop apps would benefit from multi-touch and added mobility. Seeing the iWork apps shows that Apple is serious about having complex and powerful applications on it. I can’t wait to see what people come up with, especially the kind of futuristic, concept interfaces used in movies.

As a side note, I’m planning on getting the cheapest, $499 16GB version without 3G. Getting the $829 model is a bit out of the range of a device mostly used for leisure. And I don’t think I really need that much space anyway. I don’t need my whole music library on there since I have my iPhone, and I’ll probably only put movies/tv shows on there to watch when I’m traveling. The only sticking point is 3G. I don’t travel that much, and don’t think I’d use it often, but it will be nice to have the option if I needed it. Having no contract, month-to-month 3G plans makes me consider it, but I don’t think it’s worth the extra $130.

Fixing tumblr’s white flash

January 17, 2010 - 0 Comments - tumblr

After my recent switch to tumblr, I noticed something odd. Tumblr loads their controls into an iframe in the top right corner of the page. If you’re logged in, it will give you some options to follow, like, or reblog. If you’re not logged in, it will prompt you to join tumblr. It’s not very obtrusive, and I don’t mind promoting a product I like and I hope to see succeed. The only problem is when it’s loading, the background is white, until it flashes away when the iframe is loaded and then it is transparent. This looks horrible on every site that doesn’t have a white background. You can’t turn these controls off, so it’s always there. You can configure it not to show if the user is not logged in, however, it still has to load the iframe to check if the user is logged in, so you still see the white flash.

I’ve already fixed it on my site, but here’s what it looks like:

Fortunately, it’s fairly trivial to fix this with a little CSS and Javascript. First, in your CSS, set the #tumblr_controls to be hidden: #tumblr_controls { display: none; } This will make sure the iframe isn’t showing when the page loads. One caveat, currently “tumblr_controls” is the id of the iframe Tumblr adds. If they change that id, this fix won’t work. If you know this is the only iframe you’ll ever have on your blog, you could change the #tumblr_controls just to iframe.

Next with jQuery, you can easily tell when the iframe has finished loading, and only then show it, avoiding any flash of white: $(document).ready(function() { $('#tumblr_controls').load(function() { $(this).fadeIn(); }); });

Here is the fixed version (embedded for convenience though you could refresh and look at the top right corner of this page). This gets rid of the white flash and adds a nice little fade in animation.

Switching from Wordpress to Tumblr

January 3, 2010 - 0 Comments - wordpress tumblr

I had some free time today, so I decided to switch my self-hosted Wordpress blog to Tumblr. I’ve been thinking about doing it for a while and since I want to try to post more in 2010, it seemed like the perfect time.

My main motivation behind switching is that I’ve always liked Tumblr, and have never really been a fan of Wordpress. Wordpress is a great product, but for some reason it never really clicked for me. For example, here’s a comparison of the Tumblr dashboard vs the Wordpress dashboard:


Tumblr is clean and simple, and Wordpress is a bit overwhelming and has too much going on. I’m not trying to knock Wordpress, it has gotten a lot better in the last few releases, but seems like it’s trying to be everything to everyone. Tumblr is much narrower in focus and just feels better to me. On top of that, it actually makes me want to post more, which is a feature you can’t underestimate the value of.

As an added bonus, I don’t have to worry about upgrading the software if there is a security problem, or worry about traffic spike taking down Wordpress, it’s all handled by Tumblr. It also means I don’t need MySQL anymore on my Slicehost VPS since the rest of my site is just static content, which is nice for a low-memory plan.

I’m still working out the kinks, but so far I’m pretty happy with it. Unfortunately, there was no easy way to import all my posts from Wordpress, so that had to be done manually. Luckily, I only had about 20 posts, and it didn’t take very long. The only thing I wish Tumblr had was a bit more control. For example, you can’t change how your archive page looks. Everyone’s is the same and it doesn’t match your theme, and I don’t particularly care for the layout. That and a few other little things bother me, it’s not perfect, but it’s definitely the best I’ve found so far.

NSTextView and NSString differences in text rendering

October 20, 2009 - 0 Comments - cocoa objective-c

If you’re drawing a string in Cocoa, you may notice discrepancies between how the text is rendered in a NSTextView and how it’s rendered when using the NSString (or NSAttributedString) AppKit drawing methods. This is because of they each use a different default NSTypesetterBehavior, which results in slightly different line spacings. When you draw a string using the drawing convenience methods - like [string drawAtPoint:point] - it uses NSTypesetterBehavior_10_2_WithCompatibility1. If you then place the same NSString (or NSAttributedString) into a NSTextView, it will look different because NSTextView uses NSTypesetterLatestBehavior. This isn’t a huge problem unless you’re rendering them right next to/on top of each other. For example, drawing a string into a NSCell in a NSTableView, then dynamically overlaying a NSTextView for selecting/editing. In that case, the text will jump around and it will look horrible.

Fortunately, after much searching, I found there is an easy solution. You need to change the typesetter behavior of the NSTextView’s underlying NSLayoutManager, since I don’t believe there is a way to the change the typesetter behavior of the string drawing methods.

[[textView layoutManager] setTypesetterBehavior:NSTypesetterBehavior_10_2_WithCompatibility];

That’s it and your text will render exactly the same. You should also do this if you’re programmatically calculating the height of a text block before drawing, or you’ll get one height for the calculation, but when you draw the text, it won’t fit.

1Apple’s docs that mention this: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/TextLayout/Tasks/DrawingStrings.html#//apple_ref/doc/uid/20001808-SW1

« Previous Next »

ELSEWHERE...

  • Twitter
  • Github
  • Delicious
  • Flickr
  • Blog RSS feed
  • Email

© 2010 Zach Waugh