I really like the look of this for books and journals!
But, bluntly, it’s not right for tags. We want people to feel they can create, modify, and destroy them quickly. Whereas mucking about with books and other collections is a more permanent and weighty set of actions, particularly when you get into metadata.
One way I think about it in this particular page is that books and other collections are clickable – that is, you can click into them and get more panes. Tags aren’t. That feels like enough of a behavioral differentiator to make the listing interface somewhat different for the two.
More practically: let’s set ourselves the concrete goal of shipping something collection-related at the end of this week. The one thing I can tell you is that this interface will change over time as we see how people use it. I think we’ll probably want to have Deepak take a look at it, etc.
So given that, what are you thinking is the best path forward? If I were to vote, it would be to use these squares for non-tags, the list interface we had for tags, first principles be damned. I’m open to other options. But at this point I think we’ve reached diminishing returns for interface, so let’s make a decision and go for it.
I agree with all of this; mostly, I’m hesitant to show tags (in rows) and everything else (in a grid) on the same page. I’ll try out a few ways of visually separating them and see where it gets me.
Replacing the “type to create” interface with some larger calls to action that double as little explainers for each kind of collection. Clicking on them triggers a textbox to name and create the collection — we could maybe add more controls to this dialog in the future!
Segregating tags and non-tags into different tabs. I don’t absolutely love this, but I think we have to do it if we want two different kinds of collection display, otherwise one just seems to get lost beneath/is secondary to the other. I’m thinking the tabs only appear if each of “Tags” and “Other collections” has at least one item to display.
This happens to nicely settle the problem we’d been talking about where new collections might appear beneath the fold, leaving the user confused – we can just sort them by newest first.
I’m trying to wrap up this exploration by tomorrow, because I still have a handful of other cleanup tasks to do before we can launch Collections.
Great discussion - sorry to be jumping in so late. At the risk of throwing a wrench in the works, I’d like to throw in my two cents and some quick mockups.
I’m still uncomfortable about treating tags and non-tags as different things. Both visually and in the way you edit them. It introduces a new hierarchy within collections that I think will cause confusion. There are two needs here that I can see:
Admins need a way to know they’re in the right place when their goal is ‘create a book’.
Different types of collections mandate different metadata
If that’s right, it feels like added complexity and clunk to introduce a sense of ‘lesser’ and ‘greater’ collections, some of which are clickable, some of which are shown in a list, some of which etc…
I think we’re being held up a bit by not giving tags the same editing interface as other types of collections. All collections should be edited the same way. If there is strong push against this, I think we have two different things - and they shouldn’t all be called ‘collections’ (in which case I’ll push strongly against that ). Also - collections in general are edited infrequently (except for adding content) - so I don’t feel too tied to the inline title editor, page setting, or privacy setting.
Here’s a mockup in that direction - I think it’s okay for all collections to feel like a ‘bucket’ (so - more than just a list item). And some buckets have more metadata than others.
We could even make the buckets a bit more slim so that tags don’t feel too heavy:
When you have lots, I think it looks nice - and the filtering tools lets you find what you want quickly:
It still feels weird to me to have tags be so weighty. But I think your filter interface with smaller boxes is a good enough compromise for now – and then we can spend some more time examining the underlying assumptions later when we have a bit more time to dedicate to it.
So unless there are serious objections, let’s move forward on that interface and get something out the door.
Ian, I like the click to create interface. Let me know what you need from me – text wise or a review session etc – to fill in there.
I like the shape and size we’re converging on here. There’s a few unknowns left to address about this design:
We currently have space for the “linked page”, privacy, and delete controls on the collection tiles themselves. This design makes it look like we’ll have to drop those for lack of space. I don’t have a problem with that, necessarily, since all of those controls are available from collection settings, but something to think about.
I like the idea of showing the pub count, but that’s going to be the first thing I’ll drop here since I might need to do some work to make querying that information performant.
One of the sillier ideas I had was skeumorphising the collections so that the number of “pages” in the tile grew with the number of constituent pubs…
Dropping that and requiring a click-through seems fine. Most tags in the new universe won’t need these settings anyway, they’ll mostly be applied to other types of collections.
Totally fine if this slips, but I also like it as a feature in the future. And yeah, we definitely need a better way to get and index count and similar data performantly. Add it to the list?
I was able to retain the collection-level delete/privacy/page settings just by putting them in an overflow menu, which I’m pretty happy about — I feel relatively strongly that these options are fairly high-touch and I would like them to be there without having to dig into the collection > details pane.
I’ve decided to make the collection itself a click target that leads to the collection editor — I think the underlining and cursor change makes it obvious what’s going to happen, but we could also add an explicit “update” button.
Still haven’t looked at getting pub count until I clean some other stuff up, and I’m probably going to indefinitely defer putting any kind of metadata-per-se (like the ISBN) on these; it feels like a big of a can of worms inside of a can of worms to decide what should be displayed when, and I don’t think it’s the best use of the screen real estate.
Speaking of which! Travis and I were chatting about the difficulties of truncating collection titles in CSS — there’s no cross-browser support for saying something like “give me three lines and then an ellipsis” — your choices are:
Fit the whole title on one line and cut it off with ellipsis ("…")
Fit the whole title in a given space, possibly on multiple lines, and just cut it off visually (i.e. overflow: hidden) if it exceeds its boundaries
Use a JS library to solve this problem.
I’m tentatively going with (2) for now. I like the larger titles and they currently have three lines of space to work with, which I think is sufficient. I’ve tweaked the height in terms of em so you get up to three lines of title and it cuts off sans-ellipsis, which I think will work in almost every case:
I guess the only other lingering question is around the somewhat fanciful design of the collection tiles. I kind of like having them be something other than just a rectangle — I have this vague idea in my mind about developing visual language for the various entity types (pub, page, collection, community) on PubPub — but I’m not too opinionated about it overall. Getting excited to ship this soon!
@gabestein if you feel inclined to do a copy pass of the text in the “create” boxes up top, that’d be nice. I think the copy is fine, but it’s pretty arbitrary.
Awesome - I pulled down the code and played with it a bit and it’s feeling nice. I like the overflow menu - and am fine with the title/metadata as you have it at the moment.
I do think these are still too fanciful though. To Gabe’s earlier point, they’re too heavy for Tags.
Along the lines of a visual language though, I’m fully supportive of that, and we have given it some thought in the past:
Pubs are generally horizontal blocks - and are reminiscent of the Pub Header that you see on an actual pub page.
Pages are vertical blocks - and are reminiscent of a longer, scrollable, web page.
People are circles - reminiscent of the fact that humans are really just a bunch of circles (…?)
Communities are short horizontal blocks - reminiscent of the ubiquitous header bar each community has.
If we follow that trend - where the representation of the item mimics how the element is seen in the ‘wild’ - I actually think plain rectangles is the right way to go. We use the collections with a ‘Tag’ UI on pub headers.
I’m happy to push up some commits to make style changes. But wanted a go ahead from you first so I don’t cause any conflicts.
So I really appreciate that response, Travis, and the visual taxonomy of PubPub! My last post was rate-limited by the Whole Foods pizza slice that I was cramming into my mouth with my other hand.
While plain rectangles are currently the visual metaphor for tags, I can see a case for making those more heavyweight in the future, now that they encompass the entire world of collections. For now though I agree with keeping the collection tiles simple, as shown here:
In the quest to find the right “weightiness” that feels appropriate for tags + other collections, I’ve cut these down to two lines, closer to the size that Travis proposed above. At two lines the title space already feels a bit squashed — and to me it feels important that the titles get some visual prominence above body text at at least 1.2em — but I like this just as much as the three-line version from before.
URL: The URL for the issue. Default: a search page for the collection or, if 'Link to Page’ option is set in Details, the page the collection links to.
I think we should probably make that true. It’s the only real ‘ugh’ moment I had when testing the feature.
). Also - collections in general are edited infrequently (except for adding content) - so I don’t feel too tied to the inline title editor, page setting, or privacy setting.
Dropping that and requiring a click-through seems fine. Most tags in the new universe won’t need these settings anyway, they’ll mostly be applied to other types of collections.
