
Basecamp Next: UI Preview - fbuilesv
http://37signals.com/svn/posts/3111-basecamp-next-ui-preview
======
bretthopper
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.

~~~
jasonfried
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.

~~~
bretthopper
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.

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

~~~
bretthopper
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).

~~~
BryanB55
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.

------
rguldener
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)

------
andrewingram
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.

~~~
jasonfried
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.

~~~
andrewingram
Thanks for the reply Jason,

It all sounds good, looking forward to seeing it!

------
rglover
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.

------
Pewpewarrows
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 ;)

~~~
rhizome
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

~~~
bonzoesc
It's orthogonal to pushState.

------
atacrawl
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.

~~~
lukifer
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.

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

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

~~~
rsanheim
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 ?

~~~
sstephenson
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.

~~~
hello_moto
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?

~~~
sstephenson
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.

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

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

P.S. everyones favorite new word is skeuomorph

------
tnorthcutt
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?

~~~
jasonfried
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.

~~~
tnorthcutt
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?

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

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

This sentence is sooo very apple.

~~~
BryanB55
ha I was thinking the exact same thing.

------
Alexandervn
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.

------
jon_wolfe
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>

------
jstsch
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.

~~~
jasonfried
Yes, we made sure the back button works.

------
tomkin
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.

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

------
alberth
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.

------
wickchuck
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?

------
farlington
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.

~~~
robertp
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.

------
kellishaver
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.

------
Loic
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.

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

------
capex
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.

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

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

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

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

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

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

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

~~~
remi
<http://webdesignerwall.com/demo/css3-image-styles/>

~~~
caublestone
Awesome thanks!

------
joedev
Nice job.

------
CubicleNinjas
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!

