solarbird: (Default)
solarbird ([personal profile] solarbird) wrote in [site community profile] dw_suggestions2017-04-08 07:40 pm

"Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip

Title:
"Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip

Area:
navigation strip, messaging

Summary:
It is currently very easy to configure your Inbox to serve as an activity notification hub. It would be very useful to have a shorted version of the first page of that Inbox be accessible via a dropdown on the Navigation Strip, and allow some manipulation of your Inbox via that dropdown.

Description:
Each line of the proposed dropdown would contain a one line description of the activity. (N replied to [your post|comment], N messaged you, subject "", N posted to group X, and so on). Each entry would contain an "x" dismissal button which would delete the notification from both the Inbox and the dropdown. Clicking on an individual entry outside of the dismissal button would take you to the item about which you are being notified - the message, the comment made, etc - and mark it as read. A "see all" entry at the bottom of the dropdown could take you to the current Inbox view. Currently, using the Inbox as a notification centre results in large numbers of page swaps and reloads, as you go from Inbox to post to Inbox to reply form to Inbox etc., etc., etc., with mark-as-read and delete-item as separate actions across separate pages. Further, it is difficult to maintain (de-clutter, etc) without engaging in that maintenance as a separate task. As a result, those of us who have this issue end up with over-full Inboxes that we tend to bulk-delete. This suggested feature would allow us both to use our Inbox more easily and maintain it more effectively, resulting in improved usability of the service and - hopefully - fewer notifications being stored on the servers.

Poll #18205 "Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip
Open to: Registered Users, detailed results viewable to: All, participants: 30


This suggestion:

View Answers

Should be implemented as-is.
5 (16.7%)

Should be implemented with changes. (please comment)
5 (16.7%)

Shouldn't be implemented.
5 (16.7%)

(I have no opinion)
15 (50.0%)

(Other: please comment)
0 (0.0%)

marahmarie: Sheep go to heaven, goats go to hell (Default)

[personal profile] marahmarie 2017-04-16 04:03 am (UTC)(link)
The thing is, it would force me to use the navbar, which I'm currently not using on my own journal (just on other people's - but I'm not even sure why I have it set like that, because I don't like using it).

If not for that I'd vote yes; a possible "with changes" might be making a new navbar for this alone (or setting the existing navbar to display this alone, instead of displaying all the traditional navbar stuff), which I'll think about as I eat the chili I just got done making). :)

ETA: my "with changes" is that the functionality is coded into the navbar in such a way that it's like an added strip laying across the top of the navbar (but still nested within navbar HTML so it can be styled and even displayed separately, if one so desires).
Edited (eta, typos) 2017-04-16 04:13 (UTC)
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-04-17 05:56 am (UTC)(link)
I am pretty sure the navstrip is targetable via CSS, yes! (But if you have specific improvements you think would make it better, mock it up and show us and we'll see if we should change it in general. *g*)
marahmarie: Sheep go to heaven, goats go to hell (Default)

[personal profile] marahmarie 2017-04-18 03:02 am (UTC)(link)
(I mean, if nothing else, can we at least get the text baselines to match up?

So, if I'm reading you right, I use custom CSS for the navbar that *might* do what you want - not a lot - just enough to make it more in tune with the design on my DW (which is custom, but not originally made by me, just poked at enough by me via CSS that it no longer looks exactly like the original).

I'll set it to display on my journal in a few minutes and keep it that way (showing when you click through) until you get to see it - tell me what you think! The CSS I'm using (if it helps you do anything design-wise with the navabr) is the following (as is anything below or in my style sheet that starts with #lj_controlstrip):



Copying/pasting into another DW layout might not work perfectly because I don't always keep all my CSS chunks for different parts of the page in one spot (that's most of it, above; I just can't guarantee that's all of it without going through the rest of my style sheet), so if you run into any funkiness in trying to use it, let me know.
Edited (typos/clarity) 2017-04-18 03:04 (UTC)

(no subject)

[personal profile] marahmarie - 2017-04-18 06:12 (UTC) - Expand

(no subject)

[personal profile] marahmarie - 2017-04-18 06:23 (UTC) - Expand

(no subject)

[personal profile] marahmarie - 2017-04-18 06:44 (UTC) - Expand
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

Re: also, i must note that it's part of a bigger problem

[staff profile] denise 2017-04-17 09:09 am (UTC)(link)
Oh man, I'm trying so fucking hard not to make fierce grabby hands at you right now, you have no idea. We don't have a lot of graphic design experience in our core team, and it definitely shows! (We're a little better at UI/UX design, but even with that, a lot of times we're winging it.) I'd love it if you put together mockups of a few potential options you think would work better -- from "minor tweaks to make it look better/present information better but not change things massively" all the way to "completely redesign everything from the ground up", even, if you wanted. We're not proud; we're happy to consider improvements on just about anything. :)

(If you have style fixes for text overlap and block problems and the like, meanwhile -- for any of our styles, I mean, not just for the one you're using -- I will make grabby hands over those, too! Overflow display bugs are always annoying, because no matter how good your test-case journal is during development, there will always be stuff cropping up once a style hits the Real World with Real World Data. Ditto if you have suggestions or redesigns for other pages. LOOK, WE JUST MAKE GRABBY HANDS AT ANYONE WHO SO MUCH AS SAYS THE WORD 'DESIGN' NEAR US OKAY)

There are a few caveats:

* The thing that does the navstrip on journals and the thing that does the menus/top quicklinks on site-skinned pages are generated in totally different places, so they can't be merged. (And not every site skin has the action links in the same places -- for instance, Celerity puts it on the left side, as do Gradation Horizontal and Gradation Vertical. Tropo Red/Purple are actually the only ones that put the quick action links on the right, in fact.) We are totally up for considering a new site skin or changes to the existing ones! But that all runs through a different system.

* We use Foundation as a framework on site pages -- like, the site skins themselves are not done in Foundation, and neither are journals, but the individual page layouts are. We try to standardize as much as possible and use everything entirely out-of-the-box with minimal customization, because the more you fuck with things, the more you run the risk of introducing bugs. So we can't always match a wireframe or a mock exactly: it all depends on what you can coax Foundation into doing.

* Sometimes, things are less optimal than they could be, design and display-wise, because in a contest between "does this look good" and "is this accessible to people who use screenreaders, have low vision, navigate entirely by keyboard and can't use the mouse, etc", accessible wins every time. I mean, don't get me wrong, it's definitely possible to do both; accessibility and aesthetics aren't mutually exclusive. But in the event of a conflict, accessibility always wins.

* Our users (and I say this with great affection and the acknowledgement that I am totally also one of those people) are exceptionally persnickety about both how things look in general and about things they're used to changing. This doesn't mean that we can't/won't change or redesign things, but it does mean that when we're dealing with heavily used/frequently visited pages, or with things like the site skin that display on so many pages or the navstrip that displays on so many journals, we usually try to run things through a few rounds of opinions/feedback. Sometimes the feedback that we get can be really demoralizing for the person/people who designed the first version, because people aren't always restrained about how they deliver their feedback! So just be aware of that, heh.

* We don't have a super great process for design discussion/work (mostly because we don't have a lot of people wanting to do design) -- we used to use [site community profile] dw_design, but usage kind of trailed off. (People weren't using it because people weren't using it, yadda.) If you're interested, though, I could figure something out.

(Oh, also, I forgot to mention: the reason the text isn't vertical-align consistent in the navbar is because it's done with tables and the different elements in the leftmost and rightmost table cells (logout button, mini-icon, search box) nudge the text down a bit differently. Not unfixable, with a bit of tinkering, but the perpetual line of thought goes something like "it would be better to redo the code so it doesn't involve tables, and if we're doing that we might as well spruce it up a little or improve what links/modules are in it, and if we do that we're going to have to find someone to redesign the thing, ugh, let's just go do something else on the priority list instead". That line of thought happens a lot with shit that needs redesigning, heh.)
Edited 2017-04-17 09:13 (UTC)
fiddlingfrog: (Default)

Re: also, i must note that it's part of a bigger problem

[personal profile] fiddlingfrog 2017-04-18 02:09 pm (UTC)(link)
I think it might even be worth considering a navbar which can also serve as the display engine for all of these cases

This was the best part (in fact, I think it was the main goal) of the new LiveJournal site scheme introduced a few years ago. Having a consistent UI that tracks across the site, and can be adaptable both to the relationship you have with the page you're viewing and the size screen you're using would do a lot to improve the general DW experience.

Edit: Hmm. Okay, looking closer I see that the top banner and the navigation strip are still separate parts, but that they've been designed to fit together better with no repetition of links between them. Also, the top banner has taken the place of the navigation strip as the element that floats at the top of all page views.
Edited 2017-04-18 14:25 (UTC)
marahmarie: Sheep go to heaven, goats go to hell (Default)

Re: version 2 roughs

[personal profile] marahmarie 2017-04-18 03:32 am (UTC)(link)
Huh, so I posted my code before seeing/reading through the rest of this thread. Your mockups look really good! I like how you stick with the system style but still improve gradients, text size and alignment and button styles, which is *a lot* more than I've done. I've basically done a lot of work to get the navbar to blend in with the rest of the custom layout and so it resizes properly on mobile, but not too much else.

Re: version 2 roughs

[personal profile] marahmarie - 2017-04-18 06:18 (UTC) - Expand

Re: version 2 roughs

[personal profile] marahmarie - 2017-04-18 06:50 (UTC) - Expand

Re: version 2 roughs

[personal profile] marahmarie - 2017-04-18 07:46 (UTC) - Expand
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

Re: version 2 roughs

[staff profile] denise 2017-04-18 08:27 pm (UTC)(link)
Oooh, I really like these. Have you tried it on a journal when you're logged out?
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

Re: thoughts on a more substantial change

[staff profile] denise 2017-04-18 08:58 pm (UTC)(link)
I really like that grouping, and it makes a lot of sense!

I'm 100% for getting rid of the current multisearch box in group 3 and replacing it with a textbox that calls out to https://www.dreamwidth.org/search (the directory is, well, a mess, and most of the options in the multisearch box are less useful than they were in 2001), with a small "member search" link underneath for the directory...

Anyway, yes: I would love to see mockups, since you've articulated a bunch of stuff that annoys me subconsciously about where shit is in the navstrip. (Which is still the version LJ had at the time of our fork, with tweaks over the years here and there to shove in more stuff where it would fit: that's why the style stuff is in Cell 3, because the relationship info in Cell Two can get really long.)

Views I'd want to take a look at:

* the front page of your own journal while you are logged in
* the front page of a journal when you are not logged in
* the front page of someone else's journal/a community while you are logged in (with one each of both the shorter relationship texts -- "You subscribe to [staff profile] denise", etc -- and the longer ones -- "You and [staff profile] denise have mutual subscriptions and you have granted access to [staff profile] denise" or whatever)
* your own reading page (logged in and not)
* someone else's reading page (with both short and long relationship text)
* individual entries

I'd also like to see how it behaves on both small viewports and large ones, but that can be decided by whoever implements it. (Although if you want to come up with both desktop and mobile versions, I'm pretty sure we do have the technical capacity to choose which to show to people based on their device.)

Don't feel like you have to keep the three-cell concept if you think something else will work better. (Several cells and then the relationship text centered across the entire width of the view, top or bottom, is something I've thought of a few times!) I'd also prefer if it were no much larger than the existing 60px height, although that might be tougher.
Edited (i can use my own site's markup, really i can) 2017-04-18 20:58 (UTC)

(no subject)

[personal profile] momijizukamori - 2017-04-29 03:29 (UTC) - Expand

(no subject)

[personal profile] momijizukamori - 2017-04-29 16:31 (UTC) - Expand
marahmarie: Sheep go to heaven, goats go to hell (Default)

[personal profile] marahmarie 2017-04-18 03:10 am (UTC)(link)
I'm not proposing that the current inbox go away;

I know, but I'm actually excited about the idea of having an Inbox strip above or below the navbar strip, so the top of the strip, say, is the Inbox, with the original navbar stuff showing beneath that, or any variation on that theme that sort of lets the Inbox nav be styled separately.

My idea for it (assuming this gets implemented; I hope it will) would be to sort of display:none everything navbar related just for my view of it, but leave the Inbox strip of the navbar visible, because I absolutely love the idea of having it handy on every page as I browse Dreamwidth.
Edited (typos) 2017-04-18 03:12 (UTC)
brainwane: My smiling face in front of a brick wall, May 2015. (Default)

[personal profile] brainwane 2017-04-16 08:34 am (UTC)(link)
Currently, using the Inbox as a notification centre results in large numbers of page swaps and reloads, as you go from Inbox to post to Inbox to reply form to Inbox etc., etc., etc., with mark-as-read and delete-item as separate actions across separate pages.

I hadn't thought about this until you mentioned it but maybe this is indeed why my Dreamwidth inbox is stuffed to overflowing and I don't interact with it much!
susanreads: my avatar, a white woman with brown hair and glasses (Default)

[personal profile] susanreads 2017-04-16 09:37 pm (UTC)(link)
I wouldn't use this, but as long as it's optional I don't care. But Each entry would contain an "x" dismissal button which would delete the notification from both the Inbox and the dropdown sounds like an accident waiting to happen. Deleting things from the inbox is permanent, isn't it? I can see people deleting things when they meant to get rid of the dropdown, especially if it appears on the navbar without having to be configured first.
anaraine: The (green-haired) Harvest Goddess from the Harvest Moon franchise, looking disgruntled with her hands on her hips. ([harvest moon] disgruntled)

[personal profile] anaraine 2017-04-17 06:15 am (UTC)(link)
I'm leaning towards 'no' because of how I use the inbox myself - but honestly, the biggest detractor for me is the Each entry would contain an "x" dismissal button which would delete the notification from both the Inbox and the dropdown. I'd be clicking that 'x' all the time to dismiss the notif - and then swearing a second later as I realized I also deleted the message. Which is a me problem, I get it, and I could probably retrain myself eventually. But it also sounds like a hundred Support requests waiting to happen, with no way to retrieve the deleted messages/notifs.
anaraine: Pony, from Another Wonderful Life, sitting on a fencepost and chatting with the Harvest Sprites. ([harvest moon] sitting on a fencepost)

[personal profile] anaraine 2017-04-17 06:37 am (UTC)(link)
My bad - thanks for the clarification.

I still have a bit of beef with how easy it is to delete, but I get that's part of what you're chasing after - so maybe this feature just isn't for me. (In which case, I'd love to be able to toggle this on/off. Which I know, decision fatigue, but I'll change my vote to "with changes" and wish you the best.)