Dave 24 Feb 06

That’s very interesting Ryan. Do you document those sketches later or just throw them away?

Anyway, the file uploader really needs a redesign. I bet no one leaves a description.

Is this loving you are giving to BC has abything to do with office live. I read “This means war” on this blog not long ago.

RS 24 Feb 06

Do you document those sketches later or just throw them away?

That one is already in the trash :)

JF 24 Feb 06

Is this loving you are giving to BC has anything to do with office live.

No, we’re just shifting our attention back to Basecamp for a bit to fix up and add some things we’ve been meaning to deal with but haven’t had time.

First comes the Basecamp API (next week, hopefully), then the new files section (and related functionality).

Don Wilson 24 Feb 06

Did you code the page using just an HTML document or did you do it through a development version of BC? Would you suggest that the process of coding the form in basic HTML then coverting it into your BC code would be easier when you’re just designing the layout?

Rabbit 24 Feb 06

Book! BOOOK!!! :) :) :)

JF 24 Feb 06

Don, we do the screens in HTML inside Basecamp on the dev server and hook up any existing functionality we can to the new designs.

After that we ping David or Jamis (or whoever is working on the back-end of this iteration) letting them know the new screens are ready for implementation.

They hook up what remains, we play with it, adjust, play with it, adjust, and then commit it for the next push.

Campfire has proven invaluable for this process too. We talk about it real time, share screenshots of it in real time, use it and explain tweaks in real time, and then scream PUSH IT in real-time. And since Campfire keeps a record of the entire conversation we can always look back and see what we did right and what we did wrong.

Don Wilson 24 Feb 06

Interesting.

I love seeing an insiders look of the development of a project like this.

FredS 24 Feb 06

Haven’t added Sam and Marcel yet? Ouch.

HP 24 Feb 06

Awesome work! While hot on basecamp work, any chance Campfire will be added to B.C.? Man ‘o man do we love our basecamp! Having Campfire on it would rock.

I think the file upload changes are great - labeling the files isn’t all that important I don’t think.

JF 24 Feb 06

We will be working on some hooks between Campfire and Basecamp, yes.

Phil 24 Feb 06

I must totally be missing something, because when I read this kind of stuff on your site, I keep having the “why are they doing it backwards than everything I’ve read” thought bubble over my head. Alot of your advice sounds contrary to years of people telling me things like: it’s easier to change a design sketch with pencil or a spec word document than it is to change code, or “start with the datamodel and work towards the front-end”.

It seems wiser to me to spend 2 hours sketching - iterating through ideas very quickly - and then 10 minutes coding the right thing. Can you give us more detail into the whys of this approach? What happens if the idea sketched in 10 minutes and coded for 2 hours turns out to be the wrong direction after some discussion? What am I missing?

gwg 24 Feb 06

I love this stuff on SVN. Thanks!

Phil: If you have something that takes 10 minutes to code, you probably don’t need to sketch it all, much less two hours.

If you’ve sketched for 10 minutes, you should have several, if not dozens of sketches from which to decide. If one sketch takes you 10 minutes, you’re not sketching; you’re either *drawing* or you’re sketching with too many people watching.

I’ve never understood why people insist on starting with the data model and then forcing some convoluted front end and frustrated user to fit into the data model.

Just my humble opinion.

Phil 24 Feb 06

“If sketching takes more than 10 minutes, you’re drawing.” Excellent point!

It sounds like you’re saying, “starting from the data model makes for bad interface”. Good; now we’re getting somewhere! I don’t think starting from a data model *always* makes for bad interface; it certainly can. We’ve all seen enough sites that are evidence of this. But I think bad interface comes from people who are not good at interface; not data models :-)

I do agree that starting from a good front end will result in a good front end, eventually.

More things I’m missing? Oh, besides the obvious: results. “This year we shipped 5 products, a framework, and 2 books; what have YOU done, Phil?” :-D

I guess I need the reasons/motivation/thougth behind it all, because I’m not the type who comes up with gorgeous interfaces in 10 minutes.

Tracey 24 Feb 06

Phil,

I believe I know what you are missing about this post. This redesign does’nt appear to change the data model of the application, it just re-designs (or aligns, heh) the page.

As he said in this post, the notification page is already shared with other pages in Basecamp.

After completing the sketch, you complete the markup of the HTML and someone goes into the code and as David says ‘sprinkle some Ruby tags’ in there. :)

That’s one of the beautiful parts of Rails, you could just extract common templates and reuse them somewhere else.

I hope this makes sense, because I am not an expert.

Peter Cooper 24 Feb 06

You should put the sketches up on eBay rather than in the trash. I swear if you announced it here on the blog someone would pay for them.

Jin 24 Feb 06

I wonder if the drawing was done on a napkin….

Waleed 24 Feb 06

37s-

I upload files regularly, almost on a daily basis so my team and I can exchange files long distance easily and quickly (hence, Basecamp).

Category-
I look forward to the Category feature. We’ve been creating a category in the Messages and posting all our files through that to help organize everything. A file category system would be quite handy.

Label-
I find the label feature to be far more useful then the Optional Description since a quick label usually explains far more then a description does. If I need to explain a file out longer, I usually post a message and attach the file to that message and it automatically shows up in the Files tab as well.

Request/Suggestions-
I would request that the label feature be kept.
Secondly, I would like to suggest a feature for the Files tab. Just like you can add 10 milestones at once, how about a multiple file page? They don’t have to upload simultanesouly (hence avoiding the 10mb limit) but atleast putting forth all files names at once will save me time from going back and repeatedly adding additional files every 2 mins to a message.

Thanks guys.

-Waleed, Basecamp user.

RS 25 Feb 06

Phil said..

It seems wiser to me to spend 2 hours sketching - iterating through ideas very quickly - and then 10 minutes coding the right thing.

If you spend 2 hours sketching, that’s 2 hours spent with your imagination — not with the realities of browsers, markup, pixels and code.

If you design a house on paper, you can make a nice structure. That’s fine. But if you design on site, you can find a beautiful tree, and place a window in just the right spot, so that people in their living room can see the tree.

You can’t do that on paper because you don’t have enough information about the real environment. That’s why you go step by step, imagining and building, always in a cycle, to make sure each bit of vision fits with reality.

Nick 25 Feb 06

CATEGORIES!!!!!

Yay! Now… what about TaDa list?

Thanks guys!

Moral of the Story:
Giving feedback does work.

You have made my day.

Jeff 25 Feb 06

PLEASE work on the 10-20meg upload limit! Its the one glaring hole in basecamp and major reason why people can justify it. The work arounds are hacks. There are many Java Uploaders out there that work great.

Please please please

C-Hack 25 Feb 06

Another vote for multiple file uploads. I’ve always thought it very odd that the Messages tab allows multiple file uploads but the (seemingly more powerful and purpose-built) Files tab does not. If via Waleed’s method above, all the better. His is a good idea because it extents an already successful and used metaphor.

Category implementation is very good. Thanks.

I would miss the “long explanatory text” and “Labeling” as I use both regularly. Remember, some people like me use BC as essentially a record with legal and contractual implications. As such, really thorough documentation is important. Please at least consider keeping the label. Don’t force people to rename their files for upload.

So glad BC is gett’n the love!

Tom Hemingway 25 Feb 06

I too would really miss the long explanatory/description field. I use it all the time and write long descriptions there to save people from downloading docs they didn’t really want. The label is also useful since I often change the name of a file to make it more uniform with similar docs on BC. But thanks, too, for sharing about the process.

Dave 25 Feb 06

How do you handle the fact that the Label is now gone, and that people have been using it for a year now? When showing an uploaded file, is it as simple as “if the label field in the DB is not blank, display it; else don’t display it” and let the field die out, or are you taking another angle?

JF 25 Feb 06

Yeah Dave that’s how it works. If it’s there we show it, if not we don’t.

Re: multiple file uploads, we are planning to add this as well. We’re just showing you part of what we’re doing here.

Tom Greenhaw 25 Feb 06

This is the same methodology we have been using for some years with a couple of (probably familiar) twists.

We do this on a whiteboard with a few subject matter experts. We also use a projector on the whiteboard to show existing systems.

There is an rapid iterative process and discussion to tune the interface, and sometimes its relationship with other functional components and screens in the system.

When it looks good we take a picture of the whiteboard of the rough sketches with a digital camera and start coding.

The UI typically defines the data model at this point. No long winded SDLC design by commitee documents are required.

I’d say the addage “A picture is worth a thousand words” fits very well here, and for many projects a sketch is the best design spec document possible.

I’m begginning to understand that the elegance of your systems flow naturally from your design methodology.

Elsie 25 Feb 06

I’m currently using Basecamp for a team project. Though we try to upload through ftp ourselves (more organized for files), a couple team members have uploaded through Basecamp before. I noticed that when they have, they often created a message first and attached a file if they had something to say (reason for not using descriptions). We also try to name our files well enough that the name is apparent. I can see how other people may use labels and descriptions if they don’t start through a message — different way of thinking and performing the same action. Categories will be very useful.

Regarding your last screenshot, what is “Tilted”?

The verb “tilt” means to incline, to charge, to joust, to engage in combat…

Rabbit 25 Feb 06

Tilted is their host, I imagine. See the bottom of this page? Ah… the light.

brad 25 Feb 06

Regarding your last screenshot, what is �Tilted�?

Their webhost…if you look at the very bottom of this page you’ll see a footer with a link.

The Voice of Reason 25 Feb 06

Before I say this, please understand that I do really like your products, and use them almost on a daily basis. That said …

It’s pretty dangerous to preach that you can capture an entire interaction, which usually has multiple steps and/or states, with a single, static sketch. You simply can’t surface all the assumptions and potential issues the interaction might face with a single sketch. A well-written use case would be a far more effective place to start. I’m not saying sketches are insufficient - many times they are perfectly acceptable for such small tasks as a single screen redesign - just that one lone sketch can’t capture the whole design unless the screen contains no interactions.

Most things are simply not as simple as you’d like people to believe they are. And it’s really misleading to throw around advice like this all the time, because statements like “You�ll be making the real screen in five minutes anyway” lead to other well-known, shameful axioms like “Design is what a programmer does for the twenty minutes before coding.” Your approaches are often 100% inline with the same bad practices that led to bloatware to begin with. The fact that you do it well does *not* mean anyone listening to you will be able to replicate your success, or even come close, based exclusviely on your bumper-sticker catch phrases.

The one thing you guys always leave out is that it takes a really good designer to know what to build, what *not* to build, and how to design well. You have to know something about design, keep up on best practices, be able to apply logic and common sense in a way that most people can’t even comprehend, understand the importance of clarity and simplicity in design, as well as how to create designs that meet those goals, and then convince everyone that you’re right and be able to prove it. You have to understand users - not by paying lip-service to the concept, but by gaining a very real understanding of how people actually *use* interactive systems (as opposed to how you *think* they use interactive systems).

The Dr. Phil type advice you guys throw out on a weekly basis is just *dangerous*. No one lives in your world, and most people will never be able to design effective software as easily as you do (and, as I said, you do make effective software, despite the odds stacked against you as a result of your own advice, but you’re the *exception* and you have to know that).

So, with all due respect, you might consider adding a big disclaimer to your blog that says “Follow our advice at your own risk. Results may vary dramatically.”

Tommy 25 Feb 06

Hey Jason and Ryan. I love these type of posts and the comments that follow. If I could make one request of SVN it be that you post more about how you design and development your products.

As the VP of marketing for an virtual software company I am pretty sure my tech and customer support departments are sick of me saying “well look at what 37 Signals and Six Apart are doing.”

These type of posts actually have a direct affect on my work life. I can take these ideas, use them at work, and I look smarter then I am.

Thanks!

JF 25 Feb 06

So, with all due respect, you might consider adding a big disclaimer to your blog that says �Follow our advice at your own risk. Results may vary dramatically.�

We don’t think reasonable people need a disclaimer. Reasonable people understand that what works for one may not work for another. They understand there’s never only one solution to anything.

When we share on SvN we share our way, not the only way.

Josh Poulson 25 Feb 06

I seldom use the file upload screen, though, I always use attachments to messages. It makes for trouble, though, since files posted that way get sorted funny.

Tom Greenhaw 25 Feb 06

According to the voice of reason - “Most things are simply not as simple as you�d like people to believe they are.”

Seems to me that the design philosophy of 37 Signals is to design systems that on the surface seem very simple.

I don’t see where you suggested that all software should be designed this way. I take your suggestion to mean that this is a valid project specification technique for certain useful applications.

Personally, I believe that the simplest approach is generally the most desirable approach. Exceedingly complex systems generally fall out of disuse and crumble under the own weight. They are generally buggy and unreliable as well. I for one don’t wan’t to be a corporate drone spending time in endless discovery meetings pounding out exhaustive SDLC project specifications for overly complex business applications that are obsolete before they even get to the coding stage.

Voice of Reason too 26 Feb 06

There is also something to be said about the relationship between productivity and procrastination as it relates to that 10 minuet sketch.
Maybe Ryan understands himself, and knows that if he doesn’t get to the code quickly he could overwhelm himself in details and therefore destroy all the productivity the sketch was meant to add. So for him, regardless if it is ‘truly’ the ‘most productive’ or ‘best’ way to approach the redesign- it is the method that works. And knowing what works for you as an individual is powerful! In my book, productivity regardless of the method trumps all.

Sam 26 Feb 06

Is the 10MB limit on file uploads set in stone? If yes, can you up it, just a bit?

I’m using my own server for hosting the files and posting MP3s to share with a client. They large one are in the 8-9MB range and haven’t had a problem yet but I know there is gonna come a time when the file will be 10.2MB or something. Just wondering how the system will handle that.

JF 26 Feb 06

Sam, if you use Basecamp’s file storage the limit is 20 MB. It’s only 10 MB if you use your own FTP server.

Elsie 26 Feb 06

Tilted is their host, I imagine. See the bottom of this page? Ah� the light.

Their webhost�if you look at the very bottom of this page you�ll see a footer with a link.

Makes sense — forgot about that — thanks!

The Voice of Reason 26 Feb 06

“Maybe Ryan understands himself, and knows that if he doesn�t get to the code quickly he could overwhelm himself in details and therefore destroy all the productivity the sketch was meant to add.”

I certainly don’t mean to discredit the x-factor of motivation. Indeed, motivation is key, and I don’t want to advocate spending so much time on design and specs that the product is obsolete before it ever gets built. I understand the most important thing is not necessarily to move in the direction that’s best every single time, but rather to *keep moving forward*.

All I’m saying is that there are people reading these posts who don’t have the experience 37s has, or many others do, and are actually learning things for the first time from deceptively friendly marketing axioms like “Use the product as the spec”.

No, a reasonable person *with experience* wouldn’t need a disclaimer, but those without the experience can still be perfectly reasonable, and see that each of these statements from 37s are perfectly reasonable on the surface, and take them for proven wisdom rather than the single, potentially improper approach of one company that happens to do it well and get away with it.

Those without the Midas touch would be wise to stick to processes that are proven to work and can be repeated. The act of doing user research, writing a quick use case or spec, running a usability test, and so on, is a repeatable process that provides a safety net when you’re not capable of turning everything you touch into gold on the first try.

It reminds me of the days when Charles Barkley (the basketball player) was all over the television saying he wasn’t a role model, when, clearly, anyone with that large of an audience *is* affecting everyone paying attention to him, such as all the kids who worshipped the ground he walked on. 37s is in such a position, but with a lot of these posts, they teach things that should simply not be taught. 37s seems to realize it *is* a role model, and even seems to take pride in that notion. And why shouldn’t they be? They make great products. My only gripe is that they’re pretty much the only company to ever get away with using such shaky practices, and those listening to them without the experience to read between the lines will suffer as a result. 37s should be more responsible with what they preach.

I’ve said my peace. Do with it what you will. :)

David Heinemeier Hansson 26 Feb 06

What I believe to be dangerous is the demeaning notion of cogs in a wheel. That just adding more structure and process has a positive effect on the outcome of “the simple man”. I believe that if you treat a designer or a programmer as someone who can’t do right unless they follow A Master Plan, then you’re encouraging to live down to your expectations. Throw reason and creativity out the window in pursuit of instructions.

What our “process” is all about is to encourage applied reason and communication to the task at hand. Not the abstract notion of task, but the actual problem right here, right now. When you peel off the layers of abstraction, you’d be surprised how well most people can make reasonable choices that leads to good products.

So no, I don’t buy the “won’t somebody PLEASE think of THE CHILDREN!” scaremongering you’re cooking high. We don’t shed our responsibility as role models, we embrace it to offer a different perspective.

Elsie 26 Feb 06

I think that the Voice of Reason wasn’t trying to say that you always have to do this, this and this in order to reach the final design but that you can gain a lot of insight through the process. The Voice of Reason can say more on it since I can’t speak for him/her. As UI designers, there’s a lot to be said for your first, intuitive reactions, thoughts, reasons. I think that there’s a lot to be said for usability research and tests also (and I’m sure you guys agree since you’ve been there, done that, probably still do at times). I think that at first, many of us beginner UI designers learn a lot from user tests and such even if we have a natural understanding of users. With experience, you gain so much as well and going with a design purely off of user understanding could be more probable. Just meshing the strengths from both views — intuition, research and process are all good, but some may need more or less of those depending on what stage they’re at as UI designers.

Michael Ward 27 Feb 06

The practices preached on this blog, if used peacemeal, are probably very dangerous.

This type of approach only works if you embrace the entire idea behind fewer is more [sic]. Creating complex apps using this method would be suicide - but 37signals are not advocating a design process for complex apps.

Jeremy 27 Feb 06

There’s this recurring thread on SvN, argued both by some grand philosopher-commenters and pithy snippets alike, that 37signals’ mantras and processes don’t work out in the real world. Inside the hospitable confines of the Getting Real fish tank, yes, they’ll say, but not with my giant management team and 20,000 Java classes.

Fair enough, I can sympathize, but this sounds like anxiety born of folks’ quixotic daydreams/attempts at changing their entire organization before they figure out something simpler and within their own means: Changing their own practices so that they’re happier with what they’re doing and starting to affect broader change (maybe, if they’re lucky).

Baby steps.

Jason, David, Ryan and team answer in various ways, “reasonable people will get this.” Fair enough, but linking to testimonials from some of these reasonable people’s successes in documentary (blog) form might be valuable to a lot of 37signals’ readers who can’t overcome their own anxiety and sense of powerlessness to change their corner of their company’s world. Something that’d be neat to see more. I mean, there’s got to be that guy at Cisco who does what he does that much better and got his team hooked on applying parts of Getting Real.

Or maybe not?

Matt T. 27 Feb 06

I guess I’m the only one who likes the original screen better? With its explaining what a private file is and such.

JF 27 Feb 06

Matt, the explanations are there for the blog, they aren’t really there.

Rabbit 27 Feb 06

Hrm… Actually, Matt has a point. Even if the descriptions aren’t there in the original, what’s considered “private?”

Maybe a better label, like: Make this file available only to { company }?

pwb 28 Feb 06

Most things are simply not as simple as you�d like people to believe they are.

I totally agree.

They are *simpler*!

Chris 28 Feb 06

The Bliss of Paper and Ink.
You know, I’m getting to be a big fan of pen and paper. As much as it kills me to parrot anything, the whole “rules can be freedom” thing can ring true if you’re the one making the rules. And that’s exactly the degree of freedom you have with the paper and pen. I bought graph paper the other day because it made perfect sense that lines are for guiding curves… the lines help you get done whats in between them. There are two types of simple: simple with knowledge and simple without knowledge. The latter is sheer mindlessness, but anyone who watches enough TV has their dose. The former is what I think we’re talking about. Developer-side simplicity. Tools that make complex things simple, but without information loss (ie auto-generated classes you’re supposed to override- and so the computer only does what you already had in mind… a line on a piece of paper can mean all that, but you have to be aware of the connection). Source code that’s fun to look at. Ruby on Rails is as much Ruby as it is Rails. And when two cool things get together, other cool things happen. Like realizing when you make a picture of what you want it becomes so much closer to your reach. Creativity is from the mating of ideas, not the competition. But that’s just my opinion, I could be wrong.
I couldn’t agree more w/ Jeremy though: “Changing their own practices so that they�re happier with what they�re doing and starting to affect broader change (maybe, if they�re lucky).”
The pen and paper’s a start for me.

dri 28 Feb 06

The most valuable lesson I got out of this article is that at 37s there exists a position with the authority to do what you did and the way you did it.

In my experience, the process goes more like this:

1. Create Visio diagram showing new proposed screen
2. Send for internal IT review
3. Receive criticism from Manager, Developers and CIO
4. Change Visio diagram to reflect all the ideas from everyone (often conflicting)
5. Send for external (business unit) review
6. Receive criticism from BU due to bloated, difficult to understand UI
7. Change diagram restart process at step 2.

Days or weeks can go by before we even begin to code.

Deviation from this process has even gloomier prospects resulting in complaints and objections then recoding the finished product.

This is the byproduct of working at a stable, profitable business where a lousy application means almost nothing in terms of job security or promotion.

Congratulations on having an empowered workforce that operates with a sense of urgency.

Matt Stevens 03 Mar 06

37 Signals has done it again!

I have been a Basecamp user for about a year, and absolutely love it. It has helped me in keeping things simple while maintaining communication with my clients. I’m excited for the new “Files” feature. I just finished “Getting Real”. At first I too had a hard time embracing 37signals approach to developing, but the more and more I thought about it I couldnt help but look back at all the projects I have worked on, and seeing how if we had followed this process in the begining the product woud have launched earlier, been less bloated, and mean more to us. Thanks again 37signals for sharing your knowledge.

-M

raghavendra 31 Aug 06

hey thats really gr8 way of putting things ! in right place
coz once things sketched u know what lands where !
so its really fun …….doing programming on things of foundations laid for further refernces….good work !