I was asked the other day to compile a list of resources for a friend that wants to get started designing & building for the web.
As I was compiling the list, it dawned on me how far we’ve come. When I first started scratching the surface of this wonderful little world of ours, resources were scarce and mostly HTML for dummies-type-stuff. Nowadays, there’s an immense amount of material available in all sorts and shapes, and I’m especially keen on the recent rise of interactive courses. Sites like Treehouse, Code School and Code Academy are definitely pushing the envelope in this space, and I can only imagine where we’ll be 10 years from now.
The following list is what I came up with initially, and I’m posting it here in hopes of expanding it over time. I realize it’s quite rudimentary right now, so please chime in with your own list, or even just a single item/link, in the comments. Think of it from the perspective of a complete beginner, with no prior understanding of how a website is built. Thanks.
Interactive courses
Codeacademy - The title says it all: Web Fundamentals
Treehouse - A bit more advanced, but still great if you’re just getting your feet wet.
Code School - Advanced frontend coding (HTML, CSS and Javascript) and programming courses.
Online tutorials & references
W3 Schools - one of the first and most content-rich resources. Lots of tutorials and reference pages, all written for novices. The basic HTML & CSS stuff are great starting points, albeit a bit outdated; combine with the HTML5 & CSS3 parts when you’ve got the basics down.
HTML5 Doctor - a great site for understanding the semantics behind the new additions to HTML, and how, when and where to apply them. It does require an understanding of the basics of HTML, however.
Books
I had trouble finding the best entry-level books on website design & development, so the books on this list all require a general idea of how websites come to be.
Bulletproof Web Design, Dan Cederholm - a great resource for applying best practices to the way you build websites.
Designing with Web Standards, Jeffrey Zeldman and Ethan Marcotte - I’ve never read this myself, but I’m pretty sure the authors earned some of their stripes with this opus.
This list could easily go on forever, but these are some of the people/places I’ve found to consistenly post great articles on how to build better software for the web:
Finally, you should check out my earlier post on how to maximize your productivity when you start designing that awesome thing you have in mind. Oh, and remember: sites with pictures of funny cats will never go out of fashion. Now go and build something!
TL;DR The new Basecamp from 37signals is out, and I’ve been using it for about a month now. It’s an amazing product and, pending some minor tweaks & additions, poised to become the new standard for project management tools to adhere to.
Most project are small and short. The original Basecamp was overkill for most kinds of projects. The new Basecamp is perfect for projects of every size. Jason Fried, in the launch post on Signals vs. Noise (company blog).
I’ve used the original Basecamp (now renamed to Basecamp Classic) for a long time and I always had mixed feelings about it. It did a lot of things well, but as a whole, it often felt like a drag; keeping Basecamp updated became a task of its own.
Boy, has that changed.
Rewrite
The team at 37signals decided to start from scratch with the new Basecamp (initially dubbed Basecamp Next, or BCX, for short), and launched it as a separate product from the Classic edition, which is still available and maintained. That is a bold move: it takes balls to decide to rewrite your flagship offering, one that’s been profitable for 8 years and counting. Gotta respect that.
It’s interesting to see a company with the clout of 37signals take on The Big Rewrite, and they’ve done a very good job. Chris Bliss of VM Associates wrote a great post about their execution, which he thinks is (sort of) revolutionary:
Once the product felt dated (after ~8 years, or roughly 3 cycles in the old model) they built a brand new product from the ground up. They combined the best of both worlds: the quick feedback loop of the new model with the “ground up” approach of the old model. Brilliant.
Focus & Simplicity
The number one reason I love BCX is how it exudes simplicity and feels powerful at the same time. Every feature clearly had to fight to make the cut, which leaves a razor-sharp focus on getting things done.
A lot of people are up in arms about features from Classic that’s not in BCX, such as private items, time-tracking and Milestones (to-dos tied to an event) – all features I rarely used myself, and the app seems better off without them. It feels like a lean and focused app that complements, rather than compromise, my workflow – checking in to catch up or post an update is now quick and effortless, which was rarely the case in the past.
Attractive things work better, and the new Basecamp is testament to that. The interface is gorgeous and a joy to use, mainly because of how unobtrusive it is. Generous use of whitespace and excellent choice in colors & typography combine to form a layout that’s pleasant to work with and most importantly–gets out of my way.
There’s a lot of great details in the UI, but one that stands out is what 37signals calls page-stacking - pages as sheets of paper. This is a truly innovative approach, and it works really well. This video explains it way better than I ever could (jump to 3:20).
Human-friendly
Too many people are slaves to their email, but I totally get why most people stick with it; it’s easy and it Just Works (most of the time). I’ve tried suggesting tools like Basecamp to these people, with the same outcome every time: busy people can’t be bothered to take a new system in until the benefits are proven.
Now, people don’t have to adapt to a new system at all if it doesn’t work for them. Basecamp works incredibly well as a transparent layer on top of the regular flow of emails - I’ve been using it with my team at autobutler.dk since launch, and we’ve had none of the pushback from the last time we tried to introduce Basecamp (when only Classic was available). Some team members use Basecamp, others just use Gmail, and all of our progress on projects is recorded and gathered nicely in BCX.
This is in large part due to a new feature called Loop-in. Here’s how it works: you post something in BCX, and want to let others know about it. You tick off the usual suspects to be notified, and in addition to that, you can notify (loop-in) someone that’s not on the project by adding their email to the list of recipients:
The new loop-in feature in Basecamp
They’ll get an email with the entire conversation in reverse chronological order, and can just reply to that email. Business as usual. This works really well, even more so for when you want to include someone that’s not even a part of your company.
Overview
Another great feature is the Daily Progress page, accessible from the main navigation. This is the successor to the Dashboard in BCC, and is way better - it was called Timeline during the beta, which describes what type of overview it provides.
This global overview is complimented by each project’s Catch up on recent changes page, that lists activity day-by-day. Additionally, almost all actions in Basecamp are covered by an audit trail and undoable history, so you quickly become confident that data won’t ever wind up missing, once it’s been put in Basecamp.
Another thing that works well is how Discussions are aggregated on the main project page from all comments, on all items. This is especially great compared to the old Dashboard and Messages index, both tedious to go through when you just needed to get an idea of what was currently being discussed.
You can also have a daily catch-up mail sent to you at 7am with yesterdays progress and as always, you can subscribe to RSS feeds of your projects activity. All of these things might seem a bit daunting at first, but they’re not. Apart from the occasional overflow of emails, the team at 37signals seems to have struck a near-perfect balance with regards to how and when you catch up on a project.
Quirks
As I mentioned in the start of this post, there are some parts of the new Basecamp that rub me the wrong way. But the fact that they’re all minor details, speaks volumes about the quality of the first release.
First of all, the administration of people and their permissions/project access is a bit wonky. For example, new invitees are granted permission to create new projects by default - that surprised me a bit, but it’s not that bad. However, when compared with the fact that new projects they create aren’t initially visible to me, an Administrator and the account owner, it becomes weird. Regardless of your role & permissions in the account, you can only see projects to which you’ve explicitly been granted access. That just doesn’t feel right, especially on accounts with a set project limit.
Generally speaking, I sometimes get lost navigating between sheets (pages). I tried narrowing it down to a specific example/scenario, but I couldn’t – it’s just one of those things that’s hard to explain until you try it yourself.
I might be biased from using the Classic version, but I initially thought Todo-lists weren’t sortable by dragging and dropping - there’s no visual clues that you can do this on the items in the list. This goes for the entire list as well - they both afford clicking much more than dragging.
It also really bugs me that there’s no apparent way to delete files - it’s not a problem right now, but it will be once I’ve used a sufficient amount of the storage in my account.
Finally, I miss some mobile optimizations - but given that this is version 1.0, and that the new API was recently released, I’m confident that we’ll see some efforts in this area soon.
9/10
Overall, it’s been a long time since I was this impressed with the initial release of an app - the high expectations I had, have definitely been met.
I had the pleasure of participating in the closed beta, and it’s been really fascinating to get an inside peek of how 37signals prioritize their efforts and push back on feature creep. Their approach to building a great user experience leaves no room for compromise and it shows in the product.
If you haven’t used Basecamp before, or if you’re still using the Classic version, now is the time to switch. With a 45-day trial and a price starting at $20, it’s a no-brainer.
Sketching, wireframing, Photoshop and HTML/CSS each have their place in certain phases of the process. In this post I want to give you an idea of which method to employ and highlight the advantages and pitfalls of each.
When I work on a feature or flow, I actively question my thoughts & decisions: how does this get the job done? – does it make sense? - will it be easy to code? etc. If/when I catch myself making little or no progress towards a solution, I’ve found that it’s usually because of a lack of feedback. As designers, we all know the feeling of “going in circles” and I consider this a wasteful part of the process.
Iterative design is all about spending as little effort as possible -but no less– to make an informed decision and then ship the work, so that our feedback loop(s) may tell us where to go next. So what exactly constitutes “as little effort as possible”, and how can we minimize waste in the design process?
Sketching
A simple sketch is the natural place to begin exploring possible solutions. Most of us keep a pad and pen readily available at all times, and for good reason – this is by far the fastest way to visualize your thoughts. However, the low fidelity of the good ol’ sketch can sometimes hinder your ability to see if the direction you’re taking is worth pursuing.
A little sketching is an exploration, a lot of sketching is a procrastination Ryan Singer
Sketching should be for quick explorations of abstract concepts, isolated UI elements or for outlining high-level flows (how does one get from A to B, what screens are necessary, etc.)
The sketch is also as a great vehicle for bouncing ideas off of co-worker(s). These discussions then serve as a litmus test of how well you’ve thought through the proposed solution, and especially if it’s time to move on to a higher fidelity. You should stop sketching if a teammate expresses the need to see things in greater detail, in order to see the big picture.
Remember, your sketch is just that: a doodle. This is why being able to recognize when to sketch, and when to stop sketching, is crucial.
aside:
I personally prefer big, cardboard-like paper and a chisel-tip pen (danish shop for cheapskates, Tiger, has some great pads at DKK 50,-). This keeps me from thinking about the finer details too soon – much like premature optimization in programming, both of which should be considered wasteful.
I’ve tried out lots of iPad apps as well and found Penultimate and Draft to be my favorites - the Ten One Pogo stylus is awesome for drawing on an iPad, by the way. This is of less importance, of course - what matters is knowing when to sketch, when to stop and where to go next.
Wireframing
The wireframe is a two-headed beast: the low production cost lets you quickly visualize details a simple sketch cannot provide, especially when mocking up interactions and how a user flows through the application. But the quick and cheap affordances of wireframing also provide an invite for features to creep in through the backdoor.
The sheer breadth of readymade widgets, UI components 1 and even entire frameworks 2 for apps like OmniGraffle, makes it painless to drag in a button here and a few tabs there (most often by request from stakeholders) – and before you know it, the budget is blown implementing all these things.
Such a souped-up wireframe will ultimately take on spec-like characteristics; everything in the wireframe is expected to be implemented. More often than not, such conditions are a root cause of an agile process turned waterfall.
Still, apps like Omnigraffle or Balsamiq Mockups have no match when you need an easy way to visualize dynamic/JavaScript-driven interaction, eg. modal boxes, filling out forms, etc. – sometimes it pays to hold back on coding and explore a bit more by wireframing. The cost of trying out another idea is usually much lower in a wireframe, compared to a full-blown prototype in code.
Similarly, you may find yourself wanting to elaborate on a sketch, and need greater detail prior to moving into code and/or visuals. This is often the case when starting work on entirely new products, or large features, with no foundation to build upon and/or concepts that have yet to be fully understood.
The challenge obviously lies in striking the balance. Wireframes can and will often end up in too high fidelity - time wasted on details that would’ve been better spent on a real prototype in code.
Graffletopia has an amazing collection of stencils for Omnigraffle
Over time, Photoshop has (d)evolved into little more than a necessary evil to me – it’s a slow, bloated piece of software and it was never a good fit for web design.
My biggest issue with Photoshop is, and has always been, the lack of template hierarchy, page states and how nearly everything must be duplicated in order to be re-used. This enforces a focus on form before function, and leads to things like filler text for body copy, near-identical .psd’s with different filenames, etc.
As much as I try to avoid Photoshop, I feel that the necessary 20% of my time spent using it accounts for 80% of the waste in my process. Sure, this can be alleviated to some extent by applying some best practices like sensible layer names, grouping, etc. – but there’s just no way around the fact that simple changes quickly turn into huge tasks in your average .psd and this has always frustrated me.
I really only use PS for two things these days: rendering graphics that isn’t feasible to do in HTML/CSS, and for quickly altering the layout/dimensions of many screen elements at once.
My approach to mocking up a page is somewhat backwards – where others might do most, or all, of their work in PS, I much prefer to mark up & style as much as possible, grab a screenshot and then move into PS. This remains the easiest way to try out broad changes to the layout and general look & feel. Whenever you need to do excessive search/replacing in the code to try an idea, Photoshop is most likely an easier way to test it.
(Seeing how CSS preprocessing is proliferating these days, such global code changes are becoming less of a hassle with the advent of code re-use in stylesheets. That might prove to be another nail in the coffin for PS as an app for web design – more on that in a future post.)
HTML/CSS
Time spent mocking up a full page in Photoshop or wireframes can rarely be justified these days. Considering how many screen sizes we need to design for, I think we owe it to our stakeholders - and ourselves - to explore solutions in the natural habitat of web design, as early as possible.
I’m a big fan of designing in the browser for a number of reasons. For one, my assumptions about the UI instantly become tangible in a browser: real code, real issues. How should the app respond to a click, a form submission, etc.? These things become much more obvious when you can actually interact with the system, and not just a static representation of it.
There are limits to this approach, of course. Designing in the browser can also be a wasteful part of the process. As a rule of thumb, you should have a rough sketch to work from when you start coding. Whether the sketch is on paper, a wireframe or a .psd is not important - visualizing the concept you’re implementing is what matters.
When you start building your prototype, being sloppy is a Good Thing. Crank out the HTML you need as fast as possible, keep the CSS inline and mostly concerned with structure - dimensions and floats/positioning. Once you’ve got the basic elements laid out, you can start making decisions about how the page or component will fulfill its job and start honing in on a solution to the problem.
You want to keep the code & visuals in a state that allows rapid changes in the early phase of your prototype build. This is why inline styles make sense in the beginning; a component is self-contained, can easily be moved and most importantly – quickly discarded, without any need for removing references to it in other files. Javascript functionality is best avoided early on - you don’t want to get sucked up in some weird programming problem (and you will) when you’re just exploring solutions.
The goal is to expend as little effort as possible to gain the insights you need to inform your decisions. Once you can commit to a solution, you can start to clean up your beautiful mess - this should mostly be a matter of extracting CSS to separate files, and maybe reconsidering the HTML tags you’ve used. For example, you might have marked up an unordered list (<ul>) that turned out to have an implicit order, thus an ordered list (<ol>) is a better fit. This is called code refactoring.
So, which method is the right one?
The approach you take should be proportional to the amount of confidence in your solution and your understanding of the problem space. We’ve all tried spending too much time fiddling with a Photoshop canvas, when we should’ve been drawing lines on paper. Or reworked some code snippet a million times over, when we should’ve been using some simple dummies in a wireframe.
I hope this has provoked some thoughts about your own design process and which methods you employ at a given phase.
Share your thoughts in the comments, on twitter or anywhere else you feel like it.
About
I live in Copenhagen, Denmark with my lovely wife and our wonderful son.
I enjoy the privilege of doing what I love every day, as the creative lead of Autobutler.dk.
My day-to-day work is concerned with tweaking interfaces and code to form products that matter to people.
