Viewing all essays in #design

Mapping Burgers

I've been really excited about the projects that I've been working on at Serious Eats, and the burger map that we published yesterday is a great example of how the design and development team has been working closely with editorial to rapidly produce new areas of the site to showcase Serious Eats content. One of the things that I love about Serious Eats is the deep archive of writing about all things food, but it's always been hard to find and surface (for a number of reasons which I won't get into here).  

Kenji and the editorial team came to us at the beginning of June with an idea for a burger map for the Fourth of July; they'd choose 50 burgers and gather links and photos to previous recipes and reviews. They had a vague idea that it should be clickable but beyond that it was up to us. We told the editors to gather their data in a Google spreadsheet for now, since they're used to that workflow already, and I dove into design. 

Two early conceptual sketches in Photoshop

These days I'm using Photoshop just for rough sketching rather than fully fleshing out the entire design, which has been a major sense of relief for me. The aim is to convey overall look and feel in the vein of style tiles rather than making specific layout choices or details. For those that argue that jumping right into CSS kills creativity, I would counter that it provides a set of constraints that one must be creative within. I know what's possible and where I can push the limits. It frees me from doing theoretical finished comps in Photoshop that would never work in the real world; so many of the issues that need to be solved with a responsive design only come to light as you interact with the page, and there is no way you can see that with flat comps. And we didn't have much finished content to work with since we were working in parallel with the editors. 

Development-wise we had recently built NearMe as a way to explore and organize location-based content, but this wasn't quite the right tool for this project. However, the templating system that 29th Street Publishing had put into place was exactly what we needed. On top of that, we found a script for exporting a Google spreadsheet to JSON and an svg library called Raphael.js for the map. The script enabled the editors to continue their workflow undisturbed and we didn't need to build anything custom to store the data; maybe it won't scale if we're doing many maps a week, but we just needed to ship it quickly. 

Now we've got a reusable base of design and code that we can spin off into other projects and a better idea of where we can take things. I definitely want to explore more mapping possibilities with MapBoxLeaflet, and OpenStreetMap (this is a really inspiring example!), as I think it's an effective way to group content to tell a larger story. And I finally feel like I'm getting comfortable with the process that responsive design requires to tackle some larger changes on Serious Eats. 

Ever forward!

Prototyping and Lonestar Taco

Back in April I attended the TYPOSF conference (which I highly recommend) and one theme that ran through a lot of the talks was the move towards a rapid, incremental prototyping process with a collaborative team. Developing and running Lonestar Taco has been a very similar process. I'm mostly used to designing in the medium of the web, so it's been an interesting change of pace to work on systems in a more physical realm.

The same principles apply regardless - gathering and defining requirements, designing solutions, implementing, gathering feedback, iterating. This time though it's entirely our vision, and it feels a little funny to be in the client chair at the same time as the designer role. It's definitely harder to get perspective, so it's even more important to listen to our customers. 

Menu board over timeLonestar Taco menu over six Sundays at New Amsterdam in 2012

New Amsterdam Market gave us a chance to roll out our prototype, from the menu, the organization of the ordering line, food prep and cooking logistics, pricing, sourcing, even our social media. Every week we assessed how things went and took note of what we could improve. Sometimes it was something as simple as positioning the cooler parallel to the grill rather than perpendicular. Other times, it was realizing that propane tanks don't do so well in really cold weather and figuring out how we could adapt. We ended up creating a line of retail products that didn't require on-site cooking and selling tamales that could be kept hot on an electric induction burner. 

"Ghost of Christmas Past" Chili MarmaladeAnother experiment with retail products. This one sold out in two hours.

As in all prototyping, we gathered as much customer and team feedback as possible. We had many variables to take into account - how much was rain responsible for variation in sales? How could we increase our capacity while decrease wait time but not sacrifice quality? And how could we ensure that we were meeting our bottom line? What items were the most popular and did we price them right? There's very thin line between customers feeling like they received value for their money and being perceived as too expensive. We also made sure to talk through feedback from our team, and they always had insightful suggestions that allowed us to make incremental improvements every day. 

Although we've always been clear about our overall vision for Lonestar, it hasn't always been easy to figure out the immediate form that it should take. After last season, we collected a ton of information that is helping us with the next iteration. We're altering the design of the menu and offerings to make it easier for customers to make decisions and to streamline our service. We're focused on securing a permanent kitchen for ourselves - although the initial outlay will be larger than last season, the gains in our ability to produce food, hire staff and making our products more readily available to our customers will enable us to be a sustainable and profitable business. 

Another point from the TYPO conference that resonated with me was the fact that nothing is ever "done", you always have opportunities to improve. And that has been so true with Lonestar Taco. Of course we all have days where we felt like we fell short but it was most important to get our idea out there to give people a chance to kick the tires. I'm excited that we're returning to New Amsterdam Market this Sunday to put some of our improvements to the test and to see all of our regulars.

Why I'm a Designer

Whenever I tell people who know me as a designer that I'm working on a restaurant, I get some puzzled looks. "Don't you make web sites or you're in tech or something?", their expressions seem to say. Yes, and the web is simply a medium. What I'm fundamentally interested in as a designer is the experience that people have when interacting with one another and how the intermediary systems can help or hinder those interactions. 

Restaurants and the web are more similar than you'd initially think. Paul Ford pointed out that the web is a customer service medium - so is a restaurant. Everyone has their opinion and certainly doesn't hold back. (see Yelp and every food blog ever.) It's not called the hospitality industry for nothing! Ultimately you are accountable to your users/customers, because they will certainly vote with their feet if they don't like what you're doing. 

 The same questions arise in both mediums. What happens when someone uses an interface I've designed? How does the person on the receiving end interpret it? Was the message communicated successfully? The design process provides a set of tools to gauge success and come up with solutions to make improvements. 

For instance, we want to offer counter service in the morning and afternoon and then switch to table service in the evening. This decision came about after observing that our potential customers modify their eating habits depending on the time of day. In the morning and for lunch it's mostly people on the run, in between activities or on their way to work. In the evening, people are unwinding and socializing, they certainly don't want to stand in line. However, switching service modes is unusual for most restaurants and there isn't a shorthand way to convey that. 

How can we design the space and signage to be flexible enough to switch between the two modes of service and to make it clear upon a glance what to do when you enter the space at any given time? I constantly have to examine the interface and imagine the experience from the other side. Honing my sense of empathy is an essential part of being a designer and part of why I was attracted to the discipline in the first place. 

 When I think about a restaurant as a number of interlocking systems, I get ridiculously excited. A menu seems simple but it's not at all! It's not just the visual design of the menu, it's how the items on the menu are broken down into their components, how the prep kitchen organizes the production of those components, where the components are sourced from, if those items are even seasonally available, how to price the menu item, how the item is described on the menu, if customers understand what the item is, and the placement of the item on the menu. All of these things can be implicitly or explicitly communicated to customers and will color the overall experience. And tweaking any of these variables could drastically affect how well any given item sells, and making decisions based on collecting data and feedback can make or break the business. 

 Without a doubt I love that the design process fosters a spirit of collaboration. A tight-knit team that has good lines of communication is required for all of these projects regardless if it's a web site or a restaurant. The best projects happen when everyone feels empowered to make a significant contribution, and the systems you've designed are nothing without a team behind it. Design brings observation, empathy, and collaboration into a single process where we can put something worthwhile into the world. In the end, the form isn't as important as the relationships that these systems help build.

Not Hating WordPress

I'll start with WordPress first because most people would say it's the obvious choice. I think people get the impression that I hate it, but that's not necessarily the case! It's just never hit that sweet spot for me when it comes to my personal sites, but I've definitely chosen it for client sites in the past with no qualms.

The author has an empowered role in WordPress; for instance, the fullscreen edit view encourages focused writing and you have control over your permalinks on an individual post level. You can add custom fields and Pages and widgets and all sorts of things so authors can easily maintain content areas outside of "posts". The Quick Edit and Bulk Edit views are intuitive and streamline content management. I appreciate the levels of granularity in user roles and privacy. The markup that the WYSIWYG editor generates is surprisingly cruft free if you stick to the basics.

Asset handling is good, in the sense that you can drag and drop multiple items into the browser window, but I find the organization of assets to be a bit lacking. You can't group assets into sets and the default "slideshow" is just a bunch of square thumbnails. There are plenty of plugins though to remedy that.

I'll start with the upside on the designer/developer front: there's a huge community  so if you have a problem, chances are someone's encountered it in the past and the answer probably already exists on the Internet. Or you can ask and someone's bound to know. Plus (this is especially good for clients) you can always find someone to take over development or maintenance because the community is so large. And you know that development of the product itself isn't going to stop any time soon, it's got too much momentum behind it.

There are boatloads of great looking themes that are free or a nominal fee so you have a running start when it comes to customizing a site. Like themes, there's a galaxy of plugins so if there's something that's out of my ability or timeframe to code then I can just grab it. It's also flexible so you can build things that don't quite fit into the "blog" paradigm, and since it's dynamic your changes are reflected instantaneously.

The upfront cost is "free", but you do have to host it somewhere. Maintenance is a bit easier now that you can set it to auto-update, but you have to constantly monitor your plugins to make sure they didn't break in the upgrade. I've had a client's embedded contact form completely break for days because an update no longer allowed script tags in the post body and just stripped the whole thing out without warning.

So now comes the not-so-great things - which are all the things that made it great to begin with. The huge community can be a detriment. Sometimes the answers are just plain wrong, or a plugin may be great but then WordPress releases a new version and the developer lost interest in maintaining the plugin and you're up shit creek. Or there are security holes in the plugin that you suddenly have to deal with. It's definitely better now, but with its popularity and ubiquity (like Windows) it's always going to be a target. In the same vein, never ever use the native WordPress commenting system because you will drown in a sea of spam. Offload that to Disqus or whatnot.

The 100% dynamic aspect ends up making the site really slow if you're not careful with your queries and god forbid you're hosted on a shared server. And you'll get the dreaded "site unavailable" if you've got too much traffic. True, the right host can mitigate many of these issues (I recommend WPEngine - pricy but worth it - amazing support, a staging area built in and you can deploy with git!)  but often it's not something that the everyday person considers and is probably out of the budget of most casual writers.

Lastly, I personally dislike the templating language. I have a decent understanding of programming principles and to me it feels kludgy, hard to read and understand. Why are there multiple ways to query the database? Why do I have to reset my query every time I want a new chunk of data? The lack of separation between layers makes it tedious and it is not fun at all to deconstruct a theme. I want to focus on making the interaction great and instead I'm bogged down in wondering why the metadata field isn't outputting correctly. I'm sure there are some people who love it (more power to them) but it's just not for me.

I'd see it working well for a number of scenarios - a group blog with a moderate amount of traffic, someone who needs to take advantage of custom post types, anyone's who's willing to put a moderate amount of time on a monthly basis for maintenance or who likes to tinker. It's not good for someone who's just starting to write or a small business that basically wants the equivalent of a business card, there are more elegant solutions out there.

The only site that I administer that I'd consider using WordPress for is Lonestar Taco - mostly in thinking about inviting future staff to write and that I've had a pretty good experience in teaching novices to use it in the past. However, there seems to be a whole new crop of publishing systems out there, so I'm not going to settle for WordPress quite yet. 

What I'm Looking For in a Publishing System

The characteristics of my ideal publishing system have been rattling around in my head since I heard the news about Posterous. I haven't really done very much housekeeping on my personal sites in a while and I wanted to reevaluate my current setup. Generally I don't want to spend a ton of time on maintenance and I want the templating language to be straightforward - i don't want to spend hours sifting through a wiki trying to figure out how to output thumbnails for the latest five entries from a particular category. If I'm not familiar with the template language, a good set of examples is a prerequisite. Nice looking templates that support responsive design and slideshows out of the box is a huge plus as is deploying through git.

Not all of the sites have to be hosted on the same system but I definitely want to keep the cost low. I'd like to stick with my current host so I don't have to migrate everything and I don't want to spend hours/days backing up and archiving data, and I've never had an issue with their service.

Most pressing, A Surlee Voyage and Angrywayne need new homes because Posterous is expiring. Surlee Voyage is definitely more of an archive and I don't see either of us updating content there any time soon, it just needs to live somewhere with permanent URLs. Wayne would probably write more often on Angrywayne/Emptyhighway if there was a system he enjoyed using.

I'm also looking to move Ambienttraffic (this site), Lonestar Taco and Emptyhighway (which should probably be merged with Angrywayne) off of Movable Type because, frankly, I hate the user experience of writing and maintaining content. I actively dislike the tiny editing window and uploading images one at a time to the point where I just don't want to write anything at all. Although I have a ridiculous amount of experience writing MT templates, they just get to be really tedious. On the plus side, MT generates flat pages so I don't worry too much about load.

I did like Posterous for the ability to email posts in as it was enormously convenient in China because  the site was blocked and we often didn't have internet. In the same way, I find that I'm inspired to write when I'm offline and I can focus.  I do a lot of writing on the train and offline on my iPhone/iPad in Markdown documents but a lot of it I've never published. If I could push those Markdown documents and photos/assets from Dropbox to some other system on the server that'd be ideal for Ambienttraffic. I'd like to migrate my content from MT into the new system but it's not a requirement. It's more important to be able to handle assets well and quickly so that I can update my portfolio more regularly.

For Lonestar Taco it's a bit different. Wayne writes for Lonestar and I anticipate once we've hired more staff they'll be using it too - and I can't estimate their level of "internet' yet, so it's got to be something that is friendly both to beginners and more advanced users. Migrating data into the system with the ability to adjust permalinks is a requirement. Sharing content automatically through Twitter and Facebook are important, but so are slideshows. Lots to think about!

Next up, a "Grand Tour" of publishing systems. 

Posterous is Dead, What Should I Do?

I've been galvanized to write this because of the upcoming demise of Posterous - I've got a bunch of personal sites there and I spent most of yesterday researching this stuff and I figured it might be useful to others. Plus I couldn't sleep because I kept comparing the merits and drawbacks of each system in my head (yes, this is what I lose sleep over). I also go through a version this process for some portion of my freelance projects (mostly small businesses). There is no one perfect solution and I'm a firm believer in choosing the right tool for the job; why use a cleaver when a paring knife is really what you need? Although things change so rapidly that by next year this could be completely out of date.

[Who said blogs were dead? Note that I am focused on talking about systems that are meant for blogging or maintaining a web site in the more traditional sense rather than subcompact publishing. You can talk to my friends at 29pco about that!]

I do not take choosing a publishing system lightly because once you've chosen, you tend to be stuck with it for a while. Before I even start looking, I have a loose matrix of characteristics that I evaluate. In no particular order:

  • Data Control: We talk a lot about the cloud and how awesome it is, and all of these services have popped up to make it so easy. Offloading it though means that it could all be gone one day (see Posterous). For my personal blogs/projects I'm now leaning towards hosting everything myself, but there are definitely times when I'd rather pay and let a service deal with it.
  • Data Durability: Is the system going to totally munge the data to the point where I can't export/import it to another system? Does it mangle my content by adding unnecessary HTML tags? How much work would it take to move it someplace else? Will I have access to my data 10 years down the road, or is it just going to turn into the minidisc of data formats? The older I get the more I want to be sure that I'm future proofing my data. On the flip side, there are times when I don't want every single thing archived and it's OK if it goes into the ether. 
  • Maintenance and Performance: How much time/technical knowledge does it take to maintain the system? How vulnerable is it to spamming? Are updates available on a regular basis, is it being actively developed, and is there any support? Do sites tend to load quickly, or does it go at a snail's pace? How much tweaking will it require to get the site to feel snappy?
  • Templating Environment: I try to estimate the learning curve on the template language and how flexible it is. I look for sample templates or themes to see what can be built and how clean the markup is. A big plus to me is the ability to deploy via git. Is it going to require twenty plugins to get the functionality I want? Or does most of it come out of the box? And in the end, how much fun is it to build?
  • User Experience: This is so, so important. It doesn't matter if your data is durable if the system is so esoteric or difficult to use that no data is created in the first place. I think about how many people are going to be making content, the level of "internet" they've achieved if they're new to any given system, is it FUN to write in the system, and the amount of effort it takes to upload and maintain assets. I also consider the current workflow and if it needs to be improved. 
  • Cost: How much am I (or my client) willing to pay on a monthly basis for hosting and/or services? 
So this is generally what I think about before I even start researching systems. Up next: thinking about all this stuff in the context of my personal sites.