Please bring back in the gallery page the following features that have been removed
- Goal descriptions/titles
- Time left & required amount
- Quick add form (can be put in a slide-tab-whatever, not always shown)
With a simple comparison of the two design it should be obvious that the removal of these features does not serve much purpose. It’s not even an issue of “fitting the information” in smaller screen sizes. The iOS app has the same information as the old design with no issues.
This screenshot also highlights the value of displaying user-chosen goal titles. I really don’t understand Danny’s insistence that slugs should be the display value, too. (That’s an invitation to explain the reasoning; I’d like to understand it.)
Funny timing, as you were writing this I was writing the following to the daily beemail folks:
[…] We really want the new design to pareto-dominate  the old one, with only a handful of very carefully considered exceptions.
One pretty big violation of that that a lot of folks are unhappy about is the new exclusive emphasis on the short goalnames (aka slugs) instead of what we’ve called goal titles but what we want to think of as short goal descriptions, or, internally, goalblurbs.
Here’s our master plan: http://expost.padm.us/slug
Keeping the focus on the short goalnames is not really debatable but other things are, including how we can make the goalblurbs more prominent or being more liberal about letting people change goalnames.
 I’m never sure if anyone besides game theorists know what I mean by “pareto dominance” which sounds related to the pareto principle but is totally different. http://expost.padm.us/pareto
Thanks for that!
Okay, so perhaps part of the problem is that slugs used to just be the internal gizzard hook, and you had a title where you could put the user-friendly version of what your goal is. So everyone who created goals before the revamp had different parameters for what made a good slug than we’d have now, when the slug will also be our user-friendly reminder of what the heck it is we’ve committed ourselves to.
So that just requires an adjustment in expectation on existing users’ part. Now we need to balance short-n-sweet with sufficiently informative for new goals we create. I can get on board with that. (*)
- That leaves our old goals with slugs based on the old parameters, which are often not so awesome as display values.
- What happens if I use up “the right” slug on a goal I later quit because I didn’t set it up in a way that worked, but the underlying goal is still one I’m committed to? We’ve discussed before how it can take a few tries to get a goal set up in a way that works, especially when you’re new to BM, and having to stick with the same graph when you’ve figured out that the units / commitment need to be pretty different from what you started with is honestly kind of a no-go. (* *)
(*) As long as we can easily see our fine print on the goal. I know we can see it now if we click on the
Settings tab, but I would very much like the fine print to move to the
Statistics tab, as described in this post.
(* *) Which brings up a question: if we delete an archived goal, does the slug become available for reuse? That could remove this particular thorn.
You shouldn’t have to delete an archived goal. You should be able to change the slug (without unarchiving it).
Yes, that would break integrations etc. You probably don’t care, since the goal is archived.
you already have a feature where people can change goal titles , e.g. the now called “goal description”
Thanks for speaking up about this.
@grayson et al. - the goal titles are now visible and editable on the goal pages (we switched the wording to call them ‘descriptions’).
@apolyton et al. - the gallery now shows the goal descriptions (née titles) as well as the bare min requirement and countdown. Still some tweaks to make there but should be a vast improvement on not having it at all!
The gallery also makes better use of space to show four goals per row.
Keep poking us on the stuff that’s bothering you!
Many thanks, much better!
I really hope this isn’t the final implementation. The titles are not visible from the dashboard (so I have to click into my goal to figure out what the goal is??) and are presented in a tiny font underneath the huge slug name:
The robots-only portion of the display is totally dominant.
I fear for @dreev, he may have been converted to an android
I really don’t think there’s room to show them on the dashboard, especially if the idea is that these are the more verbose description of what the goal is. They’re visible when you mouseover the short goalname of the goal - I think that’s a pretty good compromise.
I think it’s important to keep that existing line as the most prominent thing on the goal page in order for newbees to see and understand exactly what they need to do.
Maybe we’re just going to have to agree to disagree. But it seems to me that so long as the new dashboard has a static width == lots of whitespace lying around == no space shortage, I have difficulty following your logic about there not being room to show my goal titles.
And, if we have reached an utter impasse on the slugs vs titles thing, can I at least ask for the ability to set capitalization for my slugs? I didn’t bring this up previously because I didn’t realize slugs was a holy war topic, but I hate SEEING_EVERYTHING_IN_ALL_CAPS.
Also, I’d recommend renaming “household_washer_tub_clean” to, say, “tub”. Goalname renaming has been a Bee Plus feature (for reasons discussed a bit at the bottom of http://expost.padm.us/slug which we’re implementing as I type) but we’re experimenting with changing that. (PS: @apb is writing code faster than I can write forum posts over here. This is now live!)
It’s true I’m pretty cyborgish and my UI preferences can be super idiosyncratic. But I’d just like to emulate GitHub’s treatment of repository names and Slack’s treatment of channel names. I think it’s a reasonable design choice.
PS: I can see feeling different about this if I didn’t have nice short goalnames. Here’s the top of my dashboard at the moment:
Sorry, but that’s one thing that’s never going to happen. All day long at work I deal with people saying they love looking at code like
m = sum(r)
but they also can’t spot the bug in that code. How about
meanTemp = sum(recordedTemps)
If my Beeminder dashboard is supposed to be mine, then it’s going to conform to my naming philosophy and no one else’s. Brevity is not clarity.
This is a fun philosophical disagreement! Check out this footnote on an article I once wrote about naming things: http://messymatters.com/nominology/#COD
I do accept that I won’t change your mind on that. And I appreciate that this means I’m biased against use cases that matter a lot to some users. Like the ugliness of all-caps goalnames under your naming philosophy. So I’m grateful (for real) for your pushing us towards better compromises.
I’m not actually personally attached to all-caps. I think it looks good with my super succinct goalnames but I don’t imagine lowercase would look bad. Maybe @joshpitzalis should chime in here since this may have been a very deliberate design choice.
PS, @drtall, I don’t understand your claim that static width means no space shortage.
At risk of being too snarky, it became non-philosophical when Beeminder stopped supporting one type of naming after years of supporting it.
I’d like to be able to capitalize it myself, so it could look like
Hearthstone_Victory_or_Death instead of all caps or lower case. Note that’s also not just capitalizing everything after an
(You know that what I really want is for it to display the string I enter verbatim, because that’s what titles are.)
Here’s what the new dashboard looks like on my laptop in a regular window:
Everything to the left of the red hex and to the right of
PST" is whitespace and therefore wasted. If I make the window bigger, I just get more whitespace:
I’m not at work so I can’t screenshot what it looks like on my 30" display, but the portion of the screen devoted to information is quite minimal.
I understand that verbose goal titles will take up more space, but the current dashboard gives all space beyond a constant width to whitespace. This is why there is “space shortage”; it’s not because my goal titles are too long.
As of today we support goalblurbs again (if a little crudely so far)! The old way was very bad because people would change the so-called title and be horribly confused that the slug (now known as goalname) wouldn’t change. (Philosophical background.)
Space and static width:
Ah, that makes sense to have a responsive design that does something reasonable with as much space as you give it. Do you have an example of a website that does that nicely?
As for mixed case, Slack doesn’t allow it, for example:
Not to be all copycatty but I think it’s pretty legit to cite a precedent like that from a big company where presumably huge amounts of thought went into such decisions.
GitHub does allow mixed case though. That seems reasonable, but I don’t like their slightly magical way of handling spaces:
But I’m ok with either Slack’s or GitHub’s approaches. As long as we encourage people to make short, memorable, unique, easy-to-type goalnames. The descriptions can be prominent and ubiquitously shown (if space allows) but should be always ancillary and never appear without also showing the goalname.
These are tools for programmers, not “average” people. It seems like you’re limiting your audience for no reason
Further more, the Slack and Github use cases include the user typing keyboard commands that include the chat room or the repository name/slug (so you need something short, simple (no capitals) and memorable). Beeminder does not have the same use case but mainly a visual interface. There is no reason to make things harder…
How about doing a query on current users and their average length of slugs?
As a non-programmer and Beeminder superfan, I cannot possible agree with this more. One of my favorite things about the redesign is that it now looks like “average” people are welcome too. But if the functionality is still geared toward programmers, then the aesthetic changes won’t be enough. Focus on the humans.