Basecamp Next: UI Preview | Hacker News Reader

Basecamp Next: UI Preview

37signals.com

159 pointsfbuilesv81 comments

The new "sheets" UI paradigm is strange to me. Jason mentioned a few times that they wanted to provide focus by getting rid of unnecessary design elements and chrome. But with the sheets, you actually get unneeded chrome. Your main content viewport keeps getting shifted down and to the right.

Why not just use breadcrumbs at the top to provide context? That way, the entire content area could be taken over whenever you click on a link which would be much simpler.

When you use it you'll see why breadcrumbs are inferior. Breadcrumbs don't give you a sense of place. Breadcrumbs aren't natural. It sounds like a subtle thing, but once you use it you'll see the difference. Also, sheets have a much larger click target which makes them a lot easier and faster to use.

The only purpose of breadcrumbs is to provide a sense of place. It literally tells you where you are and how you got there. And where you can easily navigate back to.

In terms of being natural, they definitely don't map to a physical analogy like your sheets do. But that's a good thing to me.

edit: I agree with the click target benefit. Although I think you could do some useful things design wise with breadcrumbs to achieve a lot of what you guys did with sheets.

If you want to get semantic, breadcrumbs don't really give you a "sense" of place, they just tell you where you've come from. These sheets actually make you feel how many levels deep you are—without having to parse a string.

Curious to hear what you think once you use it. Looking at something and using it are two very different things.

Couldn't agree more. Part of my initial reaction is also just me rebelling against the trend of using physical world analogy's to solve modern UI problems. Although at least the sheets are actually useful unlike Apple's skeuomorph UIs (see: iCal).

The first thing I thought of was how sheets are like the real world and how that makes things so much more easier to use (if done right). I'm not sure why you like to rebell against using physical world analogies? Specially for less tech savy users this gives them a better chance of understanding how the interface works if they know how the object in real life works.

I think you could do some useful things design wise with breadcrumbs

I think moving beyond the > foo > bar style of breadcrumbing is actually a big deal. who else has even tried?

My first impression was that the "sheet" visual metaphor is brilliant. I'm all for physical-world-based visual metaphors when they can be implemented well, ie. not overly obtrusive and well balanced. In addition, if the the performance is as good as it seems in the video when multiple sheets are overlayed -- that's very impressive as well. I'm very curious how it was implemented.

Previously I haven't preferred Basecamp but this new version is looking great so far.

In addition to the bigger click target, I appreciate that more information can be included in the still-visible section of each sheet. Each page in a breadcrumb trail is limited to a word or two of context, but with sheets, there's room for titles and other useful info.

I am curious...to what extent does Chrome's Preferences section inspire you with this 'sheets' design? Horizontal navigation (clicking on the side) works pretty well in Chrome (including the back button). I assume that is the case with your design too?

A close button on the top right of the sheets would be nice. Its a common metaphor these days.

Otherwise the UI looks great.

If the little bit of document sticking out on the left is clickable, that would let you go "back" no matter how far down you had scrolled, which seems like a good feature.

We used to have it clickable, but we found it was fairly easy to click by accident so we turned it off. We may bring it back down the road once we have a little more time to focus on that interaction.

Seems like a glorified back-button to me.

It is. It's also one where you don't need to remember context.

Bret Victor describes and demos this in his presentation "Inventing on Principle." [http://vimeo.com/36579366]. BCX is better than a page-based back button. By the way, back still works.

Is this just me or did somebody else think they overpresent some of the features? Take 3:20, "I can just click the Todo's link and a sheet pops over the project" - yeah sure that's cool, but that's just really what I expected, it would have been ridiculous not to have a list view of all todos! It gets even better at 3:42 - "now if I can want to dive into a specific to do item, I can just click on that to do item and look at the item, and go back to the project. No need to go to the list first" - again, isn't that just an obvious principle you'd expect any decently designed web app to follow? Yes, 37signals has nice designs and the new design looks sleek. The sheets are also a cool idea and catch up looks useful, but this ridiculous overemphasizing of completely normal "features" makes them look a bit stuck up to me. The feature set is also still pretty sparse for $49/month but that is an entirely different topic (and apparently hasn't really bothered users too much in the past)

I'm very pleasantly surprised by this. I've always been a bit cynical about Basecamp's success, but I think this new version is going to be a genuine game-changer.

I really love the sheets idea and I'll love seeing how it works out. I'm already thinking about how I could apply the idea to e-commerce sites, hopefully the interaction isn't patented.

Thinking about it now, I am wondering about a potential limitation. Sheets make sense when you have a fairly consistent starting point, ie the project overview page. But what if you're given a link to say an individual ticket? Do the sheets build up from that ticket as a starting point, rather than the project page, or do they reflect the hierarchy of the site? If it's the later, does that not mean that loading a deep page in the site is burdened by having to also load its parent pages? I assume it would be handled asynchronously, but it still seems like a lot of overhead.

Thanks Andrew.

"But what if you're given a link to say an individual ticket? Do the sheets build up from that ticket as a starting point, rather than the project page, or do they reflect the hierarchy of the site? If it's the later, does that not mean that loading a deep page in the site is burdened by having to also load its parent pages?"

We'll write this up in more detail later, but the basic answer is: Every link has a default stack and that default stack is just the project page and that item's page. So if I emailed you a to-do item URL, the stack you would see would be two pages - the project the to-do is in, and the to-do itself.

We put loads of time into thinking about all these scenarios. It's all very natural when you use it.

Thanks for the reply Jason,

It all sounds good, looking forward to seeing it!

I doubt it is patented. http://twitter.com/#!/dhh/status/168725102538661891

Really, really dig the new sheets UI. If anything is going to be "stolen" from BCX, it'll be sheets. It seems odd, but only because we're so used to traversing views. Another big lesson is that the UI itself is feather light (the restraint is impressive). Excited to play with this, wish I had an invite now.

This looks like a great redesign overall. I'm still not entirely sold on how sheets are any better than breadcrumbs, other than being a different UX implementation of the same concept. But I'll adopt a wait-and-see attitude. Playing around with it is definitely needed for something like this.

The one thing I will say though: every link better be "openable" in a new tab. While I love that you're helping me focus on one thing on the page, we're multitasking beasts at heart. If I can't Cmd-Click anything in that interface I'm going to be quite disappointed. But if you're using HTML5's pushState I'm assuming you have that already taken care of ;)

I had a similar thought, but from watching the video it appears that the sheet metaphor is just that: they aren't modal popup/overs, but separate pages, just with the page layering as a part of the design. how that interacts with pushState I don't know, but it seems significant to notice that they aren't just a series of overlayers but distinct pages. I wonder if they're going to tie this together with their recent "static pages site" so as to either cache or memorialize via conversion to statics, or as a performance hack. In Rails, something like:

after_update :generate_static_page

It's orthogonal to pushState.

Rest assured, you can cmd-click everything!

I'm not using a Mac, you insensitive clod. :(

I love the concept (and the speed, my God!) but one thing that really bugs me is the to-do list area -- it seems as though it could use a similar treatment as the discussion area. The long line lengths plus the inconsistent comment badge locations make it look really tough to scan.

I wonder if they're using pre-fetching to get that insane level of speed, or they really can roundtrip DB-driven Ajax that quickly.

Nicely done. Very fast as well, never seen a webapp load that quick. Anyone with a bit of explanation on how this is done?

Basecamp Next's speed comes from the combination of an aggressively cacheable design and HTML 5 pushState.

Can you expand on what sort of caching you are talking about? Client side caching in the JS layer, varnish or some other http level caching, some sort of server side in the Rails app itself, etc ?

All of the above.

On the app level, each fragment of markup is free of user-specific data so all users can share the same cache. (User-specific concerns are pushed down into JavaScript and CSS.) Those cache fragments are then nested, so we can cache at all levels of display: an individual to-do item, the to-do list with all its items, all to-do lists in a project, and the entire project itself.

At the HTTP level, we send an ETag in the response for every GET request. Since our app caching means we don't incur the cost of a full render, we can serve the requests very quickly and avoid sending back the contents of the page if your browser already has it.

At the JavaScript level, we cache DOM elements for every sheet you've visited in the current page load, and display them immediately (while fetching the latest version in the background) when you re-visit a URL.

Do you mean:

1) it's a single page app

2) you're using ERB fragments (or something) as "templates"

3) MVC fat-client

Is this... more or less it?

It's not a single-page app—at least not in the traditional sense. Only in the sense that we don't need to reload assets with each page change.

We are using a dash of Backbone here and there for cases where interaction speed is of utmost importance, but most of what you download over the wire is HTML.

Does the Sheet paradigm supports back-button? (just curious) if so, is it via normal browser history or AJAX '#' trickery?

Curious about how you're employing pushState. Is it through pjax or something similar?

We started out with pjax (which is awesome) but ended up rolling our own framework called Stacker which lets us have complete control over the UI.

Any plans to open source Stacker?

Not for the time being. Stacker is specifically developed for this unique UI style that we're using for Next. We don't open source our UI elements.

Twitter open sourcing bootstrap just made the whole web better. Open source projects especially. Projects like https://github.com/dcramer/sentry benefitted a lot from bootstrap.

Making UI open source helps everyone.

You know who did open source their UI elements? Twitter, with Bootstrap. And you know how awesome that was for everyone? Pretty awesome!

While I agree that Bootstrap is awesome (I use it myself), it's worth pointing out that what Twitter open sourced was not the magic of their core product, but rather the templates that they use to create internal applications. If you look at twitter.com, you don't see any of the same elements that are included in Bootstrap.

You mean besides all their UI widgets, right?

http://twitter.github.com/bootstrap/javascript.html

It's probably not that hard to reverse engineer what they are doing with Stacker.

Are you pre-caching or just caching after the first hit?

Agreed. From the video it seems like this is a great way to see overviews of what is going on. And the overview seems really simple like a natural jump from current to Next. That is a big problem I have with current basecamp. I never try to read and think about the overview page cause it is so confusing. I am either in to-do or messages. Never in overview. I can't wait to get our company basecamp moved over.

I'm guessing they preload the overview data for projects in the background while you're on the overview. You can tell the difference when he clicks one of the comments. A whole lot of nothing happens for 0.5 seconds or so, then the comment loads.

tl;dr: sheets are the greatest thing in the world, you just can't tell.

P.S. everyones favorite new word is skeuomorph

From that video, it looks like they're using the term "discussion" to refer to a single post/comment. Jason or DHH: is there a particular reason why that terminology made more sense for your product than something like "comment(s)"? Or am I misunderstanding, and a "discussion" is actually a collection of comments?

You can have a discussion on anything. A message, a to-do, an event, a file, a text document, etc.

The Discussions section aggregates everything together, no matter where it happened. It feels like the right name to us. It models the world better. You discuss things in person, you discuss things in a project.

That makes sense. I may not have asked clearly, though. Is a "discussion" a collection of one or more comments, or is each comment/post/thing its very own "discussion"?

For example, if I post "What do you guys think about this new feature?" and then you reply with "I think it's an awesome feature.", is there one discussion or are there now two discussions?

That would be one discussion. The original topic and any comments about that topic.

(replying here since jason's comment is too deep to reply to)

Thanks, that clarifies things perfectly.

"We call it page stacking and we think you’re going to love it."

This sentence is sooo very apple.

ha I was thinking the exact same thing.

Nice, I like it. It's a bit like 'dependency injection', but as an interface.

Because you know that every link will open a new sheet. And it won't bring you to somewhere completely different. Clicking a link can only show you information that was inherited somehow from the sheet you're watching.

This is an intriguing UI solution. If nothing else, it's ballsy to so radically revamp a flagship application. (I hope it doesn't receive the same reception as FCPX.)

One thing the demo left me wondering is what happens when a user opens a link to something that normally opens in a modal sheet? (if I send someone a url from my browser address bar, for instance.) Does a page load with a sheet overlaying the project homepage, or is there an alternate view for that case?

edit: I see this question was already answered by Jason: http://news.ycombinator.com/item?id=3601498

I like the tactility of this a lot. Much superior to bread crumbs. Will the back button still work? Using pushstate I presume?

If so: then you have the best of both worlds. Advanced users can still open tabs, hit backspace to quickly navigate back (or 'up' in this case) — and regular users get a radically faster and more spatial way to navigate.

Yes, we made sure the back button works.

As JF said, you can't really fully judge the sheet UI idea until you see it in action for yourself. I'm one of those people who opens a new tab while using Basecamp for each item of interest. To me, these sheets could either solve that for me, or create an entirely new problem where it becomes jarring if I still prefer my old habits.

The one thing that stands out for me is how this effects the developers who work with the Basecamp API to bring the same experience to mobile, or other devices. I feel like developers who make a Basecamp app for iPhone, for example, are going to struggle trying to find a way to make these UI elements work the way they have been intended. And yes, developers will try to emulate it.

I'm reserving judgement, but for those working to bring an experience like the web-based version, I think there will be some long-game challenges. We'll see.

Asana uses a similar sheet-based system and has managed to make it work in mobile browsers, too. Try it: https://app.asana.com

Looks like a fancier (HTML5) version of BackPack (another product from 37signals), instead of Basecamp.

Anyone else feel the same?

Basecamp Next no longer looks like a Project Management tool to me anymore, but instead - just a centralized/group info sharing app ... which is exactly what BackPack is today.

How would the architecture of basecamp next port over to the mobile web? It seems that the heavy caching and initial first hit downloading would potentially work well with mobile. Anyone want to take a stab at this?

This is real pretty. I love the stacked paper visual analogy of the 'focused' view in a project, it's so instantly visually apparent what's going on.

I wonder how many trends this UI/UX is going start.

Yesterday I started working on a "panes" page for a project and I think shifting the pane so it appears like a stacked paper make a lot of sense after seeing it in action.

I know it's a small thing, but I really just do not at all care for the round user avatars. They're distracting. They create too much movement on the page, when all I want to do is read text. Square avatars don't draw the eye away from the content nearly as much.

Edit: Can someone please explain to me why this was downvoted? I'm not complaining, if it was done for good reason, just curious. I'm not the world's most prolific HN user. If my tone came across as being too harsh, it wasn't intentional.

Very nice reuse of the concept pioneered by the Google Chrome preferences dialogs. Very nice because one directly see the inspiration, which means that it will not disturb too much the users and better because by sacrificing a bit of real estate, you show a full sheet, which better show the space feeling. Well done.

How are you migrating user data to Next? Or does it use the same underlying schema/data representations?

On a project page, the text area is like HN comments. Too wide and hard to read. Why not introduce a right-handed sidebar on the project page for just the basic navigation: Discussions, Todos, Files, Documents.

What a day. First the OS X Mountain Lion Preview and now a Basecamp Next UI Preview. Both look great!

This looks really sexy. Does this mean we can look forward to Cinco being open sourced soon too?

Eric, our plans have changed and we're no longer working on Cinco.

Will Basecamp Next use application/xhtml+xml now that it has no IE8 support?

Like most sane people we have abandoned the idea of XHTML in favor of HTML 5.

But note that they are not mutually exclusive, as HTML5 do have a XML serialization.

How do you edit images to display as circles using CSS?

http://webdesignerwall.com/demo/css3-image-styles/

Awesome thanks!

Nice job.

I'm disappointed.

The single view idea is used by many project management tools and requires a user to do the parsing. Clicks are still required to gain access to the project meat. This means quite a bit of both scrolling and clicking.

The design itself doesn't lend itself well to either behavior. Menus don't scroll with you, click targets look to be fairly small.

I'll reserve judgement until I try it myself, and 37signals need simply release this and it will be accepted with acclaim, but I'm not seeing what benefits these changes bring. That said, it is crazy fast for an early build!

Reply on news.ycombinator.com