Eric Brookfield

2 eps into The Bear S2… just a goddamn masterpiece of a piece of media we can’t talk about as a collective because of fragmented media viewing habits.

it has everything we need to be discussing in america right now:

• how running a small business that does something real is too expensive
• wanting to do something life-fulfilling that doesn’t involve making oodles of money, which everyone seems to want you to do
• real structural problems, as in the environment we live and work, covered in maintenance band-aids over the years that is finally in need of real repair
• the true cost of trying to improve your station, or someone else’s, in life
• how do we even have fun? there’s so much work to be done
• good t shirts somehow cost $75

Make it Great Again, but This Time It’ll Be Different. It will be better than it used to be, but it used to be a lot better. What didn’t work then won’t work now, but also what did work then also is not working now. So here’s Change You Can Believe in, but if you vote for it we’ll make sure the status quo remains intact.

i figured out safari tab groups. their purpose, how they’re supposed to be used.

scenario: you open a bunch of tabs loosely tied to the first tab, set A. you’re done with set A and now you do something that would start set B in a new tab, but its completely unrelated.

this is where you save set A as a tab group with a meaningful name and close that shit. its there if you need it again.

tab groups manilla folders full of semi-related bits of hypermedia in an infinite filing cabinet. you still have to open the drawer to find it and it maybe gets worse if you let it get too full, but extremely helpful when the need arises to look things up again.

the goal is to not end the day in multi-tab, multi-window hell.

its an anti- “just google it” approach, because doing that over and over for the same information throughout your life is insane. its also better than bookmarks because you’re not browsing one website, you’re engaging with a collection of living media. its your focus in tabs, captured as a group. get it?

ok the UX is atrocious, for sure. its barely discoverable and thus seemingly has minimal utility.

i think a fun way to do tab groups would be to show 5 placeholder indicators for browser tabs in the toolbar, such as semi-opaque dots in a row. once you fill those 5, reveal a “create tab group” button with a one-time popover explainer. ‘Untitled’ has to go away — use ML to just name the group for me.

Hypothesis: all difficulties in professional relationships stem from a communication imbalance. Not enough questions were asked, or politics prevents a certain kind of communication flow, or someone important didn’t have email for 12 hours.

In the era of multimodal business comms, where inter-party convos happen across all available channels — in meetings (IRL/virtual), phone calls, emails, SMS, chat apps — what all digitally-connected comms channels have in common is the ability to control notifications: how and how quickly one receives a digital bloop that something might need your attention. Let’s include calendar events here as well.

I do what works for me: zero email notifications, almost no red badges, and everything else kind of makes its way in, at least to my desktop during work hours.

But other than the one or two colleagues I may have discussed notifications with, I really can only assume what notifications others receive, and that’s probably not great.

Notifications are an important part of communicating asynchronously, but we’ve sort of left it up to the individual to decide their own notification hygiene. In the last 15orso years, I don’t recall reading anything influential about notification management on the scale of, for instance, Inbox Zero, bullet journaling or todo list workflows.

So while I assume everyone with me on Teams gets Teams notifications, it seems that sometimes follow-up emails are necessary. Was that a notification problem or something else?

Additionally, I’d like to occasionally send an email at 7pm without worrying that someone on my team thinks its urgent; I’ll never send an urgent email at 7pm and expect a response right away. I probably just had something on my mind I want to get out there. I personally assume emails to be non-urgent all of the time. Having realtime notifications for email always seemed kind of maddening to me.

Lack of notification hygiene can also lead to too many bloops, obviously, and I think having an awareness of notification management — especially disabling as many red badges as you can get away with — can lead to greater mental health. For a newly installed app, assuming that the options are either “receive notifications” or “receive no notifications” could cause the over-notified to simply disable all new notification requests by default, which is fine until it isn’t.

At the moment, having a team meeting to discuss notification standards seems like a woo-woo silicon valley-inspired business practice, but I’ve really never heard of such a thing. I’d like to hear about it though. Having a set of notification expectations seems very reasonable in 2023.

the problem is, we don’t need a lot of smart connected things. we each want one or two smart connected things.

but we each want different connected things.

that makes for a very large market of connected things. but there aren’t enough manufacturers to make them well, and they all generate knock-on effects that are unique to the user.

so there’s just a lot of really bad digital crap out there and most of it is disappointing.

If I were to start a new web app in 2023, I’d use whatever full-stack server-side framework I prefer and host it on the service that will get it standing up on a public IP address quickly. That’s my sole criteria.

Use bare metal JS for as long as you can stand. Dip into htmx or the hotwire stack when you need to get a little more fancy.

Write your own reusable components. You can even call them partials and they can even work outside of a single file. Datepickers are native now so how complex is that widget you need really?

Add icons and other assets directly to your app, like a gentleman of yore.

Just go as long as possible without having to npm install.

It’s been interesting to see how much folks have come out against the JS Framework-Driven-Development practices of the last 5-7 years, and they have some good reasons. Some of them are just telling on themselves or blaming trends for their bad decision making; I’ve made some mistakes in the name of hype myself. I don’t think React or Angular or any framework is inherently A Bad Way to Do Websites, but it’s been very frustrating for the thought leaders to only recently be waking up to the benefits of server-side generated pages — as if this is a newly discovered performance breakthrough and not the way the web worked forfucking ever.

For the most part, most web developers aren’t out there trying to move fast and break things all the time. In that environment, new dependencies that immediately solve an issue in a brittle environment are appealing, and a package manager to manage that stack of dependencies even more so. You’ve got lots of new hires to onboard and don’t have time to walk each one of them through homespun code, so why not use as many open source packages as you can.

No… most web developers are out there trying to make websites that just work, and the more senior ones remember when websites really did just work, and they know the reason was because they weren’t layered with so much shit.

When you build websites that work and are easy to reason about, and where a little more time and consideration was spent working on code instead of just splat importing functions to make the CI pipeline go brrrr, you’re building durable software. You want to be able to throw a baseball at the reinforced glass window of your code and watch it bounce back, surface unmarred.

Build something that works, make it sustainable. If you want to grow it, being able to honestly pitch durability in your code is a value-add you can tout to the right investors. Know how everything in your code works. Know where every line of code comes from (mostly your repo). Know that the modern browser environment is no longer a hellscape. Sleep soundly knowing that there are no vulnerabilities down your dependency graph that will break half your packages when you try to move hosting providers.

It’s 2023. Code like it’s 2013.

Lately, when a website gives me guff, I just do not engage with the site. I’m glad I’m not the only one.

Go further than just reading on the web. I have no tolerance for slow checkouts that want me to sign up for a website to order a cool t-shirt. Blame it on Shopfiy.

I think that whenever a dumb website script is asking you to do something, or you become physiologically agitated by the performance of a digital experience, it’s important to take a step back and assess what value its actually providing to you. Does your attention (or your wallet) deserve better?

I asked the robot:

I’m seeding a tray of black oil sunflower seeds to grow them as micro greens. Approximately how many seeds by weight will fit on a standard 1020 tray.

and it said

The number of seeds that will fit on a standard 1020 tray can vary depending on the size of the seeds and how densely they are packed. However, as a rough estimate, a standard 1020 tray measuring approximately 21.5 inches by 11 inches can hold around 2-3 ounces of black oil sunflower seeds.

now chatgpt is super wrong a lot, and that is rightfully getting attention as it starts to spew factually incorrect content onto the internet. in this case, it may be wrong, but at least I can easily weigh out 1, 2 or 3 ounces and quickly see if that’s the right amount for the tray. The alternative is “a handful” which is what I did already and that kinda works, but efficient growing is all about dialing-in the inputs for best output with least waste.

If you write code for a living, you probably follow fellow code-writers (on your favorite following service of choice) and read what they have to say about the new shiny they are currently working on. You probably follow them because they often write about their new shinys. Their new shinys are usually really shiny, and when they release a demo of shiny it’s really freakin' cool.

You probably wish you were coding something new and shiny too. So you read some tutorials and give the shiny a try. But the shiny is just so new and fragile and intricate that you quickly get to a point where you can’t do anything more with it: too confusing, kind of broken. Since you can’t do anything with the new shiny anyway — it sure as hell isn’t going into your produciton environment anytime soon — you put it away.

But other coder people on your follow lister-magigger start playing with the shiny too. Maybe enough people polish up the shine that it’s now showing up on blog posts and at conferences and the like. Pretty soon people start saying that the new shiny is really the New Way, and probably soon the Only Way.

Or at least it seems like it.

So you pick up the shiny shiny again, which is really much more brillant than it was when you first played with it. Maybe you can do more with it this time. Maybe you get lost in the super shininess of it for a whole evening.

But then you go back to working on a project with your non-shinies. Maybe it’s a big big project and now you can’t find the time to get to the shiny again.

Then a year or so goes by. In that year you’ve worked on some projects that were challenging, rewarding, frustrating and exciting, but never with the shiny.

You tried to bring up the shiny on one of your projects, but your teammates decided it wasn’t a good fit.

At this time the shiny has gotten really popular. All the cool kids use the shiny. Everyone else wants to be using the shiny. There are jobs listings in San Francisco for people that can use the shiny.

San. Fran. Cisco.

At this point, you’re obviously falling behind in your industry of code people because you’re not well-versed in the shiny. You start to get anxious about your job. You start to figure out what meatspace events you can skip so you can, finally, spend time getting up to speed with the shiny shiny.

At this point, a lot of what you do just feels like it really really could and really really should be done with the shiny.

At this point, every hour spent coding how you’re coding and not coding in the new shiny way is an hour wasted.

Stop it, please

I find it really tempting to fixate on whatever impressive new bleeding edge thing shows up at the top of a feed. I know plenty of other coders do too. That’s because we shape the news we’re interested in. We post, upvote, and RT the same shit about the same new thang at the same time during the same lull we have in the same project we’ve been working on for the last few months.

I don’t think I’m exaggerating when I imply that many of us seem to hold passionate interest in something for a few mere months before something shiny comes along that seems that much better. Even when we’re getting paid for that passion.

Look, that year that just went by where you managed to successfully do a job where you type all day and make something that makes other peoples' lives better is no minor accomplishment. It’s a fucking successful thing that you did and it is time to be proud of it.

You also haven’t mastered the tools you do every day and you know them a heck of a lot better than you do the new shiny ones, so why not try to refine something you’ve got a decent footing with rather than start all over with something new for the sake of its newness?

This post is a reflection on a recent post on Twitter’s engineering blog about moving some of the client-side UI rendering back to the server, away from Javascript.

Funny enough, I recently burned some cycles experimenting with Backbone, Spine and Ember and decided I couldn’t find any of them useful for me right now. Javascript MVC is the shiny of the moment for me. I felt defeated that I wasn’t going the extra distance to master one of these tools.

Again, NO use for any of them right now, still felt like I should be using one of them.

But straight jQuery is doing me a world of good. It’s a tool I’m very familiar with, but can’t even begin to give a decent explanation on how it works. It’s not shiny anymore, but it works amazingly well, and I need to feel better about the work I do with it.

When Blog Better Boston asked me what I was going to speak about, I said “design hacks” off the top of my head.

As the day approached and I thought more about my audience, I realized that the room would be filled with bloggers of varying degrees of technical proficiency. Something more general was in order.

The presentation wound up being something of a primer on typography & CSS. I wanted to get bloggers to understand any attempts at a redesign should start with the content, and the essence of written content is typography.

Since its relatively easy to play with type in CSS (most bloggging platforms have a user-editable “custom styles” field), I gave a quick overview of what CSS is and how to start experimenting.

We unfortunately started a little late and I hit my time limit before getting too deep into the CSS fun, but I got a couple great reactions from my first real workshop.

My slides really just supported my narration, so they don’t stand on their own well. Nonetheless, here they are:

So Apple updated the iPad the other day?

Yes.

Retina display? Faster? Better camera?

Yep.

The last one was the iPad 2 right?

Yes.

Do you know what they called the new one? The iPad 3? The iPad HD?

The New iPad.

Right.

Yeah. What’s it called?

The New iPad.

That’s what I want to know! What’s the name of it?

What do you mean? The name of the new iPad?

Right. What did Apple name the new iPad?

The New iPad.

Yes. The one they just announced. What’d they call it?

The New iPad.

The new iPad that they just announced.

The New iPad. Yes.

They named it the iPad Yes?

What?

I reached a small, nightmarish victory yesterday while testing some new styles on HipHost in IE: two of my CSS files surpassed Internet Explorer’s CSS Selector Limit for a single stylesheet file: 4095.

Yay!

Fuck.

Hm? What’s this?

Woah.

Bless is a node.js module that checks a CSS file for the IE selector limit. If it reaches it, it breaks it into smaller files and then links them all with @imports in the original foo.css file.

But we’re not running node.js. :(

After extensive Googling, there’s no good equivalent or port of Bless for Compass, Sass, Rails, or even straight Ruby.

From Compass to Bless

As a Compass user, my ideal scenario would be to run a Ruby version of Bless after every compile. A reasonable alternative would be to pass the Compass output to Bless.

Luckily there is a way to configure a callback in our compass.rb, so that certainly puts us on the right path:

on_stylesheet_saved do |filename|
    # do something with fileneame
end

We can then run the Bless executable (blessc) like this:

on_stylesheet_saved do |filename|
    system('./lib/node_modules/bless/bin/blessc',filename,'-f')
end

In the immortal words of the Apache placeholder DocumentRoot: “It works!”

Requisite Gotcha

For HipHost, we’re still on Rails 3.0. That means no asset pipeline, so we’re using the asset packager gem.

For produciton, asset packager takes the stylesheet groups you’ve defined and concatenates and minifies them. It calls these files groupname_packaged.css**, which of course screws up the @import directives Bless was kind enough to create.

My solution was to make a new stylesheet group for foo_blessed1 so at least the Blessed @imports are minified and created for production. I then just go into foo_packaged.css and manually update the path for foo_blessed1.css to foo_blessed1_packaged.css.

UPDATE: Did it.

in vendor/plugins/asset_packager/lib/synthesis/asset_package.rb find the method compress_css and add the following:

source.gsub!(/-blessed\d+/,'\0_packaged')

I’m no Ruby developer…

I took a quick stab at hacking asset_packager to do this for me, but gave up having spent too much time working on this already. Anything I accomplish will probably be pretty specific to our needs and not be worth open-sourcing, but I’ll certainly share my success when it happens.

Mixing Rails and Node.js

This approach obviously creates a non-gem dependency situation for our app. But installing node.js on any major package management system is as to easy to worry much about it:

brew/apt-get/yum install node
curl http://npmjs.org/install.sh | sh

Better solution?

Ping me if you have some ideas. Porting Bless to Ruby feels like the cleanest solution, but I may be wrong. If there’s a better way to glue node modules as dependencies to Rails apps, that could be it too.

Word of OS X 10.8 (kitty code name: Mountain Lion) dropped today. The big summary is its a continuation of the iCloud-ification of your data across all devices.

Part of the announcement was a beta release of Messages.app, formerly known as iChat. Now your iMessage conversation history syncs between your OS X machine(s) and iOS devices seamlessly.

A quick test with a friend and it works as expected. “Holla” jumps up in the conversation on the iPhone, iPad and Air almost simultaneously.

So we started using it while working on our OS X machines. Then the iOS devices went to sleep. Then things got interesting.

With a conversation happening on one device but being synced across many, knowing which device is having the conversation is key to the user experience. Apple figured this out so well that I just had to jubulate in its subtlty with this post.

When typing in Messages.app, iCloud knows your in Messages.app. When typing on the iPad, iCloud knows your on the iPad. When you’re engaged in a conversation on one device, the other devices do not get notified of new messages. This avoids cross-device notification flares currently experienced by calendar alerts, which makes for an especially noisey 9:55 AM for me.

Now say you’re working, working, working and Messages.app is out of focus. At this point, iCloud doesn’t know what you’re up to. A new message comes in. Since iCloud doesn’t know what you’ve done since the conversation stopped it notifies all your devices.

You’re still in OS X so you reply to the message via Messages.app. Now you’ve got notifications to dismiss on your iOS devices, right? Total first-world bummer, right? Nope: iCloud dismisses the notifications across devices once the conversation picks up again.

No extra X-ing out of things. No burnt seconds of your life. Just gets rid of them because it knows you’ve started talking again.

This is a total win. Anyone who’s had an IM client open on an iOS device while signed in on the desktop knows that the scenario of multiple notifications about the same thing at the same is annoying to the point of untenable. Power users might deal with it for its synchronous novelty, but real users won’t.

I imagine the entire minagerie of Notification Center-enabled OS X apps will work this way. Maybe it already works this way on iOS and I just never noticed it (I’m stingy with what I allow in my Notification Center).

Maybe I’ll finally stop being reminded of our daily scrum by three screens at the same time every morning.

Boss: Do we think if we make these changes that this content will now be above the fold?

Me: You know, when I fold my laptop the screen shuts off and I can’t use the keyboard. This is going to be the case for a lot of our users too. It’s good enough content as stands; I really don’t think its worth considering the fold.

Yes, this is obnoxious. No, not all bosses can take a joke.

I’ve got high hopes for TextMate 2, which we know is happening for sure now. But Sublime Text 2 has been my goto editor for the last few weeks now.

Plenty to like, plenty to loathe, but its refreshing and it comes in Cobalt.

But being blessed with a 27" Cinema Display, one particular feature is providing that “I can never go back to a time before this” feeling I haven’t experienced since cold folding: column view. Specifically Columns: 4 ⌥⌘4.

Right now I’m mostly wearing the hat of Front-End Rails Developer at HipHost, which means I’m dealing mostly with four types of files: Controllers, Views, SASS stylesheets, and JavaScript.

Now here’s that wish: four columns + four file types + some light OCD = Assign File Type to Column.

I should be a good developer and just figure out how to make this happen. But then there’s that free time thing…

If anyone’s interested in this, drop me a line. I can at least give a brain dump of my thoughts.

I’ve been using — nay, depending on — SaSS and Compass for at least a year (I’ll get around to contributing, I swear). At the time when I picked it up, I was not familiar with Ruby or YAML, so its indentation-based syntax took a little while for me to wrap my head around.

But HipHost uses Ruby On Rails, so I’ve gotten to know and love Ruby. I took another stab at using the SASS syntax and now I’ll never go back.

The only problem is I’ve got quite a few .scss partials that I need to convert now. Well open up that Terminal; here’s one line of bash to the rescue:

You can replace that first *.scss with **_ or _*.css* depending on what’s in your pwd. Just remember to change your from (-F) argument accordingly.

Maybe you should try LinkedIn?

As an industry, we web design-types are torpedoing into the responsively designed future while our design tools are stuck in the mockup-driven past.

We now have the know-how to serve dozens of devices, resolutions and bandwidths with one codebase and a design that adapts to its device. The old flow of designing a mockup with a 960-pixel grid, getting sign-off and coding it up is dead.

Dead, dead, dead!

We could attempt a mockup-driven approach to responsive design. Why not pick a few resolutions we want to support for an arbitrary amount of devices and then just do static mockups that address each scenario? We could, but now we’ve multiplied the amount of work we do by a factor of n, and our finished design won’t feel quite right when coded.

Not only that, but what gives you the right to only support a handful of devices? Let the user use whatever device they have in their hands to get at it.

“But everything needs to be approved by The Creative Director. That’s their job! We need to stay on-brand, on-message! Margins of exactly 12px!”

Sure, no doubt. No one wants a grumpy Creative Director. But there’s no reason why you can’t design responsively today and still please any number of stakeholders.

Design the parts, assemble the whole

What I find myself doing more and more is designing components in the browser where their context is 1:1 — no pictures of websites here, folks — where I can easily test multiple viewport sizes. (I’m not sure that component is the right word yet, but it works for now.)

For me, a component is any given idea of a thing that a good website must have:

• good typography
• a uniform set of form inputs and buttons
• navigation or chrome
• adaptive layout

Right now it’s a big, slow, dumb challenge to attempt to do all these things well in static mockups and expect the result to be pushed into code perfectly. These days, I often work on something like my header, paragraph and list styles with markup and CSS in a browser using real content, test it across multiple viewports and devices, then move on to the next component when I’m happy with the results.

You can’t do anything like this in Photoshop, Fireworks, or any other tool where the output is only vector or bitmap. The output needs to be code.

Ugh. Code?

Yeah, but just the web standards: HTML, CSS & Javascript.

Look: we create paintings with brushes and paint on canvas; we make music with things that make noises; we need to design websites with things that make web standards code, specifically good code — not too much, just for a specific component, that gracefully degrades. (This is not the article where we weigh the merits of screen designers coding their work. There are plenty out there.)

Do I smell future?

I actually started writing this article a couple days ago with no particular tool in mind, only wild fantasies of what a modern and future-forward web design app would be like.

But serendipity is a clever girl, and Gradient 1.0 was released today in the Mac App Store.

In a nut, Gradient is a remarkably intuitive tool for doing 90% of the gradients we web designers need on the regular. Just look at the first boot screen:

Gradient makes the task of designing gradients in CSS3 as easy as designing them in an image editor. With a UI like this, I might actually argue that its the most enjoyable gradient editing tool I’ve ever used.

The current problem with creating gradients using CSS3 is the boatload of vendor prefixes you need to make them work across browser, as well as having a fall-back strategy (usually a solid color) for older browsers. You can streamline this process quite a bit using SASS and especially Compass to compile your CSS, but you still have to ⌘-R your browser to see the results.

Gradient gives you a sexy interface for interactive gradient editing and outputs beautiful CSS3 instantly. With SASS support and multi-step gradients on the way, this app is a model of future web design tools. If you’re as excited about this New Way as I am, please support the Jumpzero guys by purchasing the app.

Onwards.

Preface

I am not a well-known web developer. I’ve yet to work on anything that made its way to the front page of any widely read blog or news site. I’m just a humble guy who writes a lot of code and moves a lot of pixels around all day. My voice isn’t heard by many outside of the small circles of friends, family and colleagues I interact with on a daily basis. But this isn’t stopping me from writing this post.

Reflection

Steve Jobs passed away yesterday. He was 56 years old. He built one of the world’s largest companies, selling some of the world’s most amazing and truly beautiful products.

Steve — (don’t we all feel like we’re on a first name basis with him?) — created devices that help me and millions of others get shit done every single day.

I’m part of an industry that wouldn’t be where it is today without Apple. Apple’s devices, especially the iPhone, forced competitors to catch up.

Google up operating system screenshots before and after OS X, phones that predate the iPhone vs. those that have come after, and laptops pre- and post-MacBook Air.

Steve knew we were in the future and, dammit!, the future is supposed to be shiny, sexy, and easy.

Steve broke the status quo over and over again. A rebel with a cause, practically vigilante but crazy genius for sure.

Self-Reflection

I’m trying to figure out why I feel so sad about the passing of a guy I never knew, why flowers and vigils at retail stores across the world seem so appropriate (a first of its kind, for sure).

Maybe because I never thought I had any living, breathing personal heroes.

Now I certainly have one less.

Rest in peace, Steve. And thanks for reminding everybody about the future.

When the iPad was initially release, it was touted as the ultimate digital media consumption device. Whatever you can see and hear over the Internet or on your hard drive was just going to be more enjoyable on the iPad for all sorts of reasons: form factor, ease of use, portability, etc.

It took a little while, but a few multitouch-optimized production apps started to trickle out to prove that the iPad’s unique interface makes an exceptional if not ideal digital media creation device as well, if only for certain types of media.

Djay for iPad was one of the first apps Gruber cited proving this true. Then of course came the iPad 2 and Apple’s own Garageband made its multitouch debut.

Trying to be productive

Along the way, the good folks at The Omni Group ported their much-loved diagraming app, Omnigraffle to the iPad. Being a fan of the desktop version, I sucked it up and purchased the $50 iPad app. It was probably the first productivity app for the iPad that I decided to take seriously.

Amazingly, most of the familiar Omnigraffle tools and options were there. It was impressively simple to create new objects, line them up, resize, and change their properties. Without getting too deep into it (I’m not trying to write a review here), it felt truly useful, but not robust enough to replace desktop Omnigraffle for my everyday wireframing needs.

Actually being productive

Fast-forward a year and a few months, and Omnigraffle for iPad is now at version 1.6 and has some impressive improvements. Most notably, you can import stencils from Graffletopia simply by searching and clicking. With almost zero effort, I had some of my favorite wireframing stencils ready to go.

Today I was tasked with giving the home page for HipHost a rethink for the sake of highlighting featured or seasonal tours, I decided to give Omnigraffle for iPad the old college try.

Actually using the damn thing

The goal at hand was a simple home page wireframe redesign. I usually find redesigns easier than carte blanche designing, but I wasn’t ready to jump into desktop Omnigraffle, Fireworks, or even code. I reached for the iPad and fired up Omnigraffle thinking I’d play around with a few grey boxes and figure out the big picture, then shift to the desktop.

But an hour and a half later, I had something that looked an awful lot like a complete wireframe. And I was very, very happy with the results. And very, very surprised by the time.

Single-tasking is the way to go

Multi-tasking destroys productivity. True productivity. The sort of get-shit-done productivity where you feel good, not exhausted, when its over. The single-tasking nature of the iPad means you can’t help but pour all your attention into what you set out to do.

A UI so clean, you can eat off it

When wireframing, I’m mostly doing the following:

• selecting elements
• positioning elements
• typing text
• configuring elements

Here’s how you do these things in Omnigraffle for the iPad:

• selecting elements: tap
• positioning elements: tap & hold, drag
• typing text: tap, double tap
• configuring elements: tap, tap the Inspector icon, tap a property, make changes

These are trivial examples and certain actions are more complex by nature, but they demonstrate that nothing I wanted to do ever took more time than I felt it should. I was never fumbling through menus or panels trying to figure out where some switch was that let me do what I needed to do. All the important controls just felt there.

While apps on the iPad lack power-user features like keyboard shortcuts, the right multitouch user interface at least feels efficient.