Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Basecamp Next: UI Preview

37signals.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Basecamp Next: UI Preview

#61

Post by rhizome »

Pewpewarrows wrote: post #16

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 on…

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

Re: Basecamp Next: UI Preview

#62

Post by voidfiles »

dhh wrote: post #44
gr3g wrote: post #42

Earlier quoted context omitted.

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.

Re: Basecamp Next: UI Preview

#63

Post by voidfiles »

gr3g wrote: post #42
sstephenson wrote: post #35

Earlier quoted context omitted.

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?

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

Re: Basecamp Next: UI Preview

#64

Post by 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.

Re: Basecamp Next: UI Preview

#65

Post by joedev »

andrewingram wrote: post #64

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. Sh…

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

Re: Basecamp Next: UI Preview

#66

Post by jasonfried »

andrewingram wrote: post #64

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. Sh…

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.

Re: Basecamp Next: UI Preview

#67

Post by ameribrit27 »

jasonfried wrote: post #8
bretthopper wrote: post #6

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…

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.

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.

Re: Basecamp Next: UI Preview

#68

Post by trhaynes »

tomkin wrote: post #23

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 wit…

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

Re: Basecamp Next: UI Preview

#69

Post by 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?

Re: Basecamp Next: UI Preview

#70

Post by BryanB55 »

bretthopper wrote: post #15
jasonfried wrote: post #13

Earlier quoted context omitted.

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.
Post reply on HN