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

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)

I'm not proposing that the current inbox go away; I'm proposing this as an additional view to it. So while you would have to use the navbar to use this new feature, you'd lose nothing.

(This is not an objection to having it be outside the navbar; it just struck me as the most reasonable - and least-cost - place in the current structure. Personally, I use the navbar, despite it being pretty unattractive. I've been wanting to figure out whether it could be customised. That would be nice.)

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

I am pretty sure the navstrip is targetable via CSS, yes!
That's the impression I'm under, but I'm not a web designer so I do a lot of poke-and-test with Firefox's debugger until I figure out how to make things move around. And so far I haven't figured it out. XD

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.
Seriously? Because from a design standpoint it's kind of awful and I have an art degree and have done graphic design professionally and I am 150% willing to take that on.

(I mean, if nothing else, can we at least get the text baselines to match up? Because the current floaty-random-level text is pretty painful, and stuff like that is why at least one pro designer I know personally won't use Dreamwidth. I have also fixed a bunch of things like that in the style I'm using now, problems that lead to overlapping text, non-wrapping text going behind and under other text blocks, and so on.)

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

Wow, yeah, that's a lot better just from a baseline lineup standpoint, and with a bunch less CSS than I had to use to make that happen. Nice!

I did a bunch of other stuff too (see my journal if you want, I've got the navbar on - or see the .png files I linked) but yours by itself is a big basic clarity improvement.

Thanks! I just re-did the code - after not updating it for a while, then comparing it to your .png files tonight, I decided it Needed Things, so now it has them (I took out some code, too - mostly stuff that wasn't useful).

For comparison (if you like), the new code is now:

.logged-out.has-navstrip #lj_controlstrip_userpic{visibility:hidden;margin-left:-6.6em}
#lj_controlstrip{background:#353533;padding:.5em 0;border-bottom:1px solid#444;}
#lj_controlstrip a{text-decoration:none;border-bottom:1px solid#B82E2E}
#lj_controlstrip a:hover{color:#888!important;border-bottom:1px solid #fff!important}
#lj_controlstrip input,#lj_controlstrip select,#lj_controlstrip_login,#lj_controlstrip_actionlinks,#lj_controlstrip_user,
#lj_controlstrip_userpic a,#lj_controlstrip_userpic a:hover,.cutTagControls a:hover,.icon-links a:hover{border:0;border-radius:7%}
#lj_controlstrip td{font-size:.8em;line-height:1.5}
#lj_controlstrip_userpic{margin:.6em 0 0 0}
#lj_controlstrip #Logout, #lj_controlstrip #Login{display:inline-block;font-size:1em!important;margin:0 1.15em .3em .7em;padding:.2em}
#lj_controlstrip_statustext{display:inline-table;font-size:1.1em;margin-bottom:.5em}

#lj_controlstrip_search{display:block;margin-top:-.2em}#lj_controlstrip_search input{margin-bottom:.5em}
#lj_controlstrip_search .select{padding:.3em}#lj_controlstrip_search .select + input{padding:.2em!important}

I like your smaller icons - the icon/text size in the standard is a problem, I solved it by going larger text, you solved it the other way. Both work tho'.

On Firefox right now the search text entry field is hidden behind the search-type dropdown.

I wonder if that's only in Firefox (that's what I'm using, too)? I thought DW hid it (when I remove my CSS, DW seems to also hide it). I'll check it out in other browsers, just to see.

I have it in mine, and when I view your page in my style, it reappears, and it's visible on the system default CSS as well.

(This is latest Firefox on latest formerly-OSX-now-MacOS.)

Yeah (Firefox on Win10 here), you're right.

The funny thing is, I had the search text field in there until the last moment (I had to add it, because I noticed it was missing, myself), then took it out when I thought DW wasn't using it, either (apparently they are; it's something else in my CSS obscuring it. I have that problem with my code, a lot: I need search teams to dig through it sometimes just to find what went wrong/missing/is making something look funky).

I like how you nudged search all the way to the right. Which is making me think I want to go for dividing the page into thirds and spreading the three sections more evenly (I think I only had them smashed together to make it easier to style for mobile).

And I see we both have those tiny, tiny text fields for log-in username/password when I suppress cookies to give me the logged-out view. I guess that's native to the DW design, but I'd like to work on making those boxes bigger when I get another good chunk of time.

ETA: Put the search field back in and widened the username and password boxes while I was at it. I didn't think those would wrap* on mobile, but they do! *so happy*

*Of course, now I'll have to test tonight's changes in nine browsers across three phones, two laptops and our tablets, but wheeee, it's a start! )

Edited (clarity, eta) 2017-04-18 08:16 (UTC)

Cleaning up the navbar would be only a partial solution to some of the varied UI problems. For example, the navbar orders basically the same set of options as the top banner of the profile/customisation/new post/new comment pages, but in a different order, layout, and placement on the page (far left vs. mostly far right). That - as well as the way it just looks completely different - is one of the reasons it's always felt tacked on.

It might be worth having the "use navbar?" option replace the banner on all of those other pages when the navbar is enabled. This creates consistency of experience. But I have no idea how problematic that might be on the dev side.

(From a development standpoint, I think it might even be worth considering a navbar which can also serve as the display engine for all of these cases. Swap out the backgrounds depending on context, but render the rest of it consistently across the various uses. And have the "use navbar?" option behave has it does now, but in the background be using the same code across all cases.)

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

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)

heh i didn't see this before i posted my rough drafts below. but hey! css can apply to tables at least a decent chunk of the time. But yes the navbar really needs to be redone in proper CSS because yikes some of this was hard to get to work.

anyway below is a rough draft (that's actually live on my style).

also live on my style are a bunch of CSS overlays I did to fix the wrapping problems and stuff. my profile is public, if you can see my custom CSS overlays just grab 'em if you want. some of it's just math errors that I fixed.

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)

This is a rough first draft of a minimal navbar cleanup. Reading page view, Own journal view. This is what I was able to do in CSS through the custom-CSS interface; it's now what I see live on the site when logged in.

In no small part, this is just getting text horizontally aligned with other lines of text, regularising sizes of objects, and ditching some pretty heavily dated WoAh-3D-bUtToNs. I also lost a horizontal divider, floated the search box out to the right, and re-margined the user icon so that the margins are even.

There really should be less space between the 49px user icon and the text to the right, but it's 2am and I'm sleepy. Also, the reload-in-light text is a pixel too high, see also sleepy, and really, that reload-in-light button should be with the other "viewing" actions anyway, and not the search bar, since it's another viewing action and not related to search at all. But I don't think I can do that with CSS against the generated code.

All of this is in the service of reducing visual clutter. It's also still a rough draft, because even besides the already mentioned incomplete bits, I can't fix the irregular spacing on the leftmost menu (Home / Post / Reading etc) because there's no way to hook into those in CSS that I can see. But that should be sorted out too.

This is, again, the minimal changes approach. It doesn't address the other issues I brought up of consistency across pages (except for moving the search box closer to where it is in other layouts), menu ordering, and so on, but it's less immediately visually dissonant and I'm pretty sure would be zero impact on users if implemented. But it leaves a lot of other problems unaddressed.

eta: Here, I made an A/B comparison between the current (as seen in another user's style) and my first-draft cleaned up version (as seen by applying my style to that user account).

Edited (added another image) 2017-04-17 09:38 (UTC)

Here are improved version 2 roughs. I think the differences are meaningful so just jump straight to these:

A/B comparison (another journal, current navbar vs. my style applied navbar)

Navbar, journal view

Navbar, reading page

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.

And I posted my other reply before seeing this. :D

Thanks! Those are actually live, you can hit my LJ and see it. (Also, I cleaned up the login pane as well.) There are parts that are not where I'd like them to be and I don't know that I can get them there because there aren't enough IDs and/or classes - in some places, not even paragraph tags.

(I didn't even have to change the gradient - I'm just working with it more intentionally, so it pops as a result.)

Oh, goodie! I just have to change my account to view other people's journals in their styles and I'll go have a look - thanks! (I'm really loving what you did, though, just from the .png files. If you look at the updated code in my last reply you'll see there are a few things I didn't do, like separators, gradients, and button styles - though buttons/selects now have slightly rounded borders and some padding - because the tables are so convoluted my brain just starts hurting looking at them).

Edited (typos) 2017-04-18 06:19 (UTC)

The separators - I took one out, actually, there used to be another. In general I like fewer of those, but I kind of like the one and only one here. ^_^

I also put in a lot of work on text entry boxes to make them less distracting when not looking at them - not just getting rid of the 3D like we both did, but also bringing their height more into range of the larger text. And my minimalist buttons, of course - they serve the same purpose.

And yeah, because there aren't enough IDs and/or classes is another factor. It's funny because for search alone (just for ex) there's too many IDs and not enough classes, then there's whole swaths of the navbar CSS that are just a wasteland - nothing useful there to style.

I'll look over your CSS for ideas the next time I work on my navbar, though, because you pulled a lot of classes and IDs I didn't even think of using (I did my re-working tonight just before I saw your CSS). Looks like very useful stuff. :)

I'm probably doing some things the hard way, I'm not super-great at CSS. But yeah, there are a few more classes and IDs accessible than appear at first glance. Some of 'em took a good deal of trial and error. XD

Here're my thoughts on a more substantially changed navbar, elsewhere in comments on this same post.

Read through it, thanks. Hopefully your ideas give DW/the dev team lots of food for thought.

Re: viewing all but feeds/using custom URLs, definitely +1. I use custom feeds, myself (added to the header navlinks instead of the navbar, using a custom theme layer) and dropped feeds altogether from them after my DW subscribed/access feed became too overwhelming years ago (and which it still pretty much is).

Oooh, I really like these. Have you tried it on a journal when you're logged out?

Yeah - that's how I discovered the login pane problems, that I also went after.

Anyway, that's about where the least-impact version stands for me.

I am also thinking about a more-changes version as well. As I see it, functionality is almost currently grouped by:

1) (far left) Who you are
2) (centre) Where you are/what you're seeing
3) (far right) look for things

...and solidifying that would both make the navbar more useful and easier to understand.

Keeping that in mind: Group 1 is pretty reasonable as it is. Group 2: the style viewing selector really should be with Group 2, not Group 3. Group 3 could pick up the "Support/Help" link that's missing compared to everywhere else, or some other similar bit of functionality not currently exposed. So we could talk about things like:

Group 1: Basically okay, I think. But if the user is not logged in, add a top-level "Join" option to the Login group which replaces the User group in this position, because right now, there isn't one, and... yeah. Should be.

Group 2, Own Journal View: In addition to the above notes (which apply to all Group 2 views), I'd lose "Invite someone" and replace it with "Share this." It's something that refers to where you are at the moment and accomplishes a the goals of "invite someone," depending upon how you handle the sharing. (The "so and so shared this with you" mail could have a "Join Dreamwidth" link, etc.)

Group 2, Reading Page: Add an "all but feeds" option in the dropdown. Personally I'd find that useful and you can already build that URL yourself (and I have a separate bookmark for it), but maybe that's just me.

Group 2, Individual Entry: Again, lose "Invite someone" in favour of "Share this." Change "your journal" to "your post" if on your journal, or to "a community post" if in a community. Possibly add simple "previous" and "next" icons, since it is, after all, a navigation bar.

Group 3: Keep search as is, add links under it to Help | Support | FAQ (maybe), other functionality, since the view options would be moved to Group 2.

If done tightly enough, there are opportunities to add additional functionality hooks as well. For example, in Group 3, you could have a link to the Directory Search page, which could be given a name like "Advanced Search" or "User Search" or "Member Search" to distinguish it as separate to the simple keyword dropdown search.

I could play with this if it's of interest. This would be more of a true mockup process instead of a "go ahead, implement it then take screencaps" process, but that's to be expected when adding more changes.

Edited 2017-04-18 07:07 (UTC)

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

denise", etc -- and the longer ones -- "You and

denise have mutual subscriptions and you have granted access to

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)

I tried to just message you with this, buuuuuuut...

I've just thrown a bunch of desktop navbar mockups at my readers to see what they think. Here're the graphics for 11 different views.

These can't be done with custom CSS on the existing platform, they require actual code changes, but I'm keeping the load of those changes pretty much down to the UI side, insofar as I can tell.

One functionality change is getting rid of dropdown-plus-button to trigger a view reload on the reading view, and just having the dropdown selector do it directly.

I'm also adding a lot of prev message/next message arrows (when in single-post views) and prev page/next page arrows (when in journal or reading page views). And I bumped up the RSS functionality a little bit, that's a nice feature and I suspect an opportunity.

Another question I had was whether the style selector needs to be a set of top-level links or whether it could also be an action-on-selection dropdown. Right now I'm showing it the old way.

Anyway, I don't really consider these really final but they do accomplish the general task of dividing into three consistent groups (user/login, current location, exploration) and adding some basic functionality (like prev/next) that really is kind of implied by "navbar" and so on.

The background gradient is just the standard system gradient and could be replaceable with anything.

Ha, yeah, sorry, I have to keep PMs turned off or else I get a bunch of requests for technical support or site help that just wind up sitting there when I have a three-day "ugh I can't sit up long enough to grab my laptop and type" thing like the last three days have been... (You can email me, though -- denise@dreamwidth.org.)

These look amazing and I personally love them. Lemme throw them to our senior volunteers and see what they think. (I would like to keep the style selector as top-level links, though; links are easier than a dropdown selector, and since those options are there for accessibility, it's good to keep them as easy/quickly reachable as possible.)

At this point, I gots two requests for you:

1) Can you send me a signed contributor licensing agreement? (The CLA is a bidirectional ass-covering document: it protects us from ever getting sued because we're using something that someone else came up with, and it protects you from us ever coming to you and saying "this thing you did had a bug and we're suing you because it caused problems" or "you sent us this thing and now you're stuck giving us support for it/maintaining it for us for the rest of your life". It also makes it very clear that you're not signing over copyright/ownership to your creations, just a permanent and irrevocable license to use and redistribute your creations, so everything is very clear about who owns what.)

2). Then, join

dw_dev if you want -- that's our development community -- and

dw_design, which hasn't been used in ages but I'd like to resurrect, so we can get this discussion out of the comments of a single

dw_suggestions suggestion. :)

There are a couple of changes I need to make on desktop.

1) I need to swap "home" and "help." It's a standard to have "help" on the far right, and has been for years, and that just needs to happen.

2) See this post where I talk about 'trending tags' and 'latest posts sitewide', because I have some thoughts about when to swap those in, in addition to "popular RSS feeds." One of the complaints I hear most about Dreamwidth is the difficulty of finding similarly-interested people; let's expose some of that basic functionality.

I also need to make a couple of changes to the mobile taskbar, because there really need to be visual indicators that swiping is a thing, and I kind of knew that but didn't face up to it. The standard for this is chevrons at edges. It might be enough to have the chevrons appear and fade out after one second. That would be handy.

But after more testing on my end - the mobile login panel doesn't work on smaller phones. It's too small, the touch targets are too small. And some of the arrow targets are borderline on a small smartphone - for example the iPhone 5, which is kind of my baseline of a minimum smartphone still in use. Even if you take the touch zones and implement them the entire height of the screen, it's still going to feel weird.

So that needs a second version pretty badly. But the desktop version, we're just talking small tweaks.

Can we collect all this somewhere? Like dw_design or something?

Absolutely! That was going to be my next step, once I ran it past the senior volunteers. (Just because I love something doesn't mean that my opinion is necessarily the same as others', so I didn't want to post to dw-design before getting a few other thumbs-up first. But the people who've weighed in so far all like it.)

If you want to write up a brief explanation of the various views and what they do, and toss me a second version of the mobile mockups, I can post them to dw-design for you. (I don't want to ask you to post directly, because feedback can get really heated, so usual practice is for me to post it instead so you don't get the comment notifications and have to choose to go read the feedback. But if you'd prefer to post it yourself, you totally can -- posting is open to all members.) Then, I'll link to the dw-design post in our next news post to get more eyeballs + more feedback.

I definitely like the idea of linking to the Latest Things page. The "trending tags" is a little more hit-or-miss (as you've probably noticed); it's not a very smart calculation, and because of caching, sometimes it highlights a tag that doesn't actually have any entries in it...

Navbar 3.1 for mobile:

https://www.dropbox.com/sh/gs9oqkbz9r8yrli/AADQC2pXMJtblOGhZx9Jbd3ha?dl=0

I'll try to get 3.1 for desktop sorted out in a bit, but it's pretty similar to what's up there now, just with the whole Help/Home swap and all that.

Navbar 3.1 for Desktop:

https://www.dropbox.com/sh/qkunjvslzj2os9k/AACPfnFdNenyaCFldNnn0SH_a?dl=0

Both of these directories include first drafts of design/guideline docs.

Love. Love, omg, love. (Everybody who's weighed in on them so far has also loved, btw.) The design/guideline docs are fucking awesome, too, holy shiiiiiit can we keep you?

I'll write up a draft dw-design post laying out the reasons for the change/introducing the mockups and run it by you in email to give me thumbs up/thumbs down on -- probably won't be tonight (catching up on other shit) but if we get it posted by Monday, I'll be able to include it in the next news post. Can you drop me an email (denise@dreamwidth.org) now just so I know what's the best email to use for you? (Also because my email server will impose delivery delays as an antispam feature if it's the first time someone's emailed me from that domain, and looking at your confirmed DW address, you might run into that; better to get started on waiting out the greylisting now.)

Email sent from verified account; passed greylisting, logged as successfully handed to your server at 23:59:10 Pacific/Cascadian time.

(We also run greylisting, have for years, it's a necessity.)

Another thing that needs to happen is a proper clean, simple, and responsive basic journal style - something not unlike the year styles of Wordpress, perhaps. It should be one that people can customise, of course, and it should be the default style on new accounts, and the standard version of it should be selectable view-in-style option (see also: "Mobile style" shown in the mobile navbar dropdown.) All this is in part because Dreamwidth needs to work on mobile, and right now, it mostly kinda doesn't.

I don't know whether this is something which can be handled in the current style system. Can it?

And I have fished it out of my spam folder after thinking "huh, I should have gotten that by now"!

Journal styles are more complicated than site pages, but we can definitely talk about that too! (We do have Mobility, a style that's designed to work well on mobile, but there's still a ton of stuff we can do; we've just been limited by a lack of designers and by a large percentage of the site still being in the old custom templating language that Brad dreamed up even before LJ existed. We're converting it, but sloooowly.)

I need to make a testbed account so I can play with stuff without affecting my live journal.

eta: lololol I didn't even mean that XD

("my live [as in visible online] journal here at Dreamwidth")

Edited 2017-04-28 00:21 (UTC)

Ha! Yeah, go ahead and make one and then drop me the username, I'll give it some paid time. (Or you could get an account on our hosted-developer-environments service, but a full dev environment might be overkill for you...)

heh

check out

solarbird_testbed and by that i mean check it out on a phone.

(my goal is to take the default new user style, clean it up (there are a lot of problems tbh, not the least of which is that fonts behave really differently across different browsers) and make it automatically flip into optimised-for-phone mode if viewed in such an environment.)

Edited 2017-04-28 05:15 (UTC)

yeaaaaah

I may've gone ahead and written 470 lines of new CSS for the default new user style (Neutral Good) that fixes a fleet of bugs in the style and also adds pretty functional mobile support

I mean sure, it's an alpha, but - you want mobile Dreamwidth, Artie? You got it.

solarbird_testbed and some notes on the updated style. (like, it makes no attempt to make system-style pages do anything, it's pure CSS, and so on.)

Anybody sees this, it really is an alpha, report bugs over here please.

Edited 2017-04-28 08:35 (UTC)

And I hit up the account with paid time, so you'll be able to create plenty of styles and such!

We aren't wedded to Practicality/Neutral Good as a default style, btw -- we used to run polls every six-to-nine months for the userbase to decide on what the default style for new accounts should be, but we haven't done it for a while because it's kind of a pain and there's always eight billion other things further up the list. So we can always change it. I like the first look at it and will do a full accessibility review when I get a chance!

(A lot of stuff may also be doable at the system layer without needing all that CSS, too, but I am soooo not the person to look into that;

momijizukamori does a lot of our CSS-to-S2 conversions. I'll page her in.)

Basically, it is my strident opinion that whatever the new user default style is, it must work well on both desktop and mobile.

Version 0.8 alpha released. Same place. Lots of bugs fixed, a good bit more cleanup, vastly improved comment trees on mobile. I'm using a > symbol where I'd rather be using a right-pointing black triangle but Dreamwidth's parser breaks if I use that, so I'm doing with the > for now.

D pointed me here - as she says, I'm one of the three or so people who've done the most digging around in the S2 system, as well as some digging in other sitescheme pages. I will also make grabby-hands, because I'm pretty comfortable writing code but like, design is hard and stuff, and having someone interested in that is a huge boon. I also don't use DW on mobile much so I'm a little out of touch with the problems there and what the right fixes are.

Hi!

I may've had some cider but I'm not drunk-typing. Pretty sure. Might be but it's cool.

Basically the existing default style for new users doesn't work at all well on phones and has a lot of problems on desktop for that matter so I've taken a run at fixing both problems and maybe a couple of others because I'm 140% serious, new users need to be dumped into a functional environment without crushed text and a mobile view that pretty much doesn't and other brokenness, right?

You should look at

solarbird_testbed and the read page for it, because those are all changes made with CSS to declutter/repair the desktop and add what I'm pretty sure is a lot of usability to the mobile experience.

One of the biggest problems of course is the double-margins/double-boundaries and acres of floating lines, which isn't good on desktop but is particularly problematic on a mobile device (particularly a phone) because holy crow you don't have room for that shit. Plus it's mostly just visual distraction anyway.

(Also the eye-flow on desktop is kind of "LEFT RIGHT LEFT RIGHT NOW I'M STARING INTO A BLACK VOID WHAT IS GOING oh it's just the banner, there's the journal, below it" so that kinda needed to be addressed too.)

I'm not trying to make a new style from scratch with this project tho', I'm basically trying to go with, "okay, what can we do quickly to fix the current default style so that new users get a generally functional experience straight out the gate," because what they do after that with customisation is their own lookout. XD

anyway, hiya!

For sure - though we probably can't make any changes to the desktop view and keep it the same layout, because current users will notice a 2px change in where something is, and they will revolt :P (I did the conversion of site-styled entry/comment pages from the old awful system to S2, and I'm not even exaggerating about 2px changes). On a related note, this was a thing brought to my attention by a friend last week - does it seem like a useful general stop-gap measure? It wouldn't be hard to implement across the style system more generally.

Well my proposal fundamentally is to make a new default style, which is basically the current default Version 2, and hand that to new accounts.

My primary concern at the moment is new users. People who are here already would be able to switch to it, of course, but new users could be being handed a more functional experience in very short order - at least, if the CSS layer I've been writing can be rolled out. (It would require more testing, of course, I've only been testing it on Safari and Firefox on OS X/MacOS, but still: it could be done quickly.)

Ah, okay! I misunderstood something farther up in the comment chain, carry on :) I can also maybe point more people at it for a greater range of test data if you'd like? I don't want to accidentally overwhelm you, though!

Do it. Here's the current update post - I just dropped Coexistence Alpha 0.82 which makes the mobile-only comment depth markers work all the way down. And there have been a bunch of other fixes since 0.81 as well.

Sure thing - is it also live on your test account?

It is live on

solarbird_testbed, but that is where I do my work? So that's not so much "bleeding edge" as just "bleeding," and it breaks constantly when I'm working on the code. XD

solarbird always has the current reasonably stable at the moment, and the version linked on the status post.

Edited 2017-05-01 17:46 (UTC)

also, I just had that moment where I collapsed my browser down to mobile view on my desktop to reply to this, because nested comments this deep work better in mobile view than normal desktop view.

aw. yeah. XD

Nice! I will point at the test account but leave the caveat that things may go really weird occasionally.

The release post is on my personal account, I'd really prefer not to have to update an additional post as well and would really prefer you link to that.

Specifically to here:

https://solarbird.dreamwidth.org/1533020.html

Edited 2017-05-01 17:52 (UTC)

I can do that! Mostly I wanted to be able to point people at somewhere that already has it installed if they want to have a look but not install it themselves.

Well, then go ahead and link to the testbed as well, and I'll make the intentionally-broken cannot-be-patched-around-on-mobile post friends only, and add a sticky pointing to the installation page.

0.833 is pretty far along, btw.

(Updated links and data: https://solarbird.dreamwidth.org/1533020.html )

Is there a way to detect whether accessibility is on in comments so we don't have two depth number systems running at once?

There should be, at the S2 level if nothing else. I'll dig into it and let you know.

Thanks!

Also - and I suspect the answer is "lol no" - if there's a way to hook the "new post" screen I'd love to know about that, too. It's the last major barrier to ordinary use on phones.

By new post screen, do you mean http://www.dreamwidth.org/update ? There's a beta for a new version you can opt into at http://www.dreamwidth.org/beta - I don't know what we're still waiting on before it's default-ready. Unfortunately because it's a site page and not on a journal subdomain, it's not hookable, no.

Yeah, I'm one of the five people in the world who historically need to use disable pre-formatting so the beta version is an issue for me personally. Still, I should turn it on so I can see whether it handles mobile better.

If you do, you can switch back at any point! Or manually disable auto-formatting by wrapping your entry in <raw-code> / </raw-code> tags...

(Also, if you look at the CSS code I've been writing, you'll see that I'm invoking something very similar but on an inline basis - that's how I'm doing my responsive work.)

My thoughts are on mobile are that the three cells remain, but one is displayed at a time, and the other two are reached by swiping. Default to the middle pane, simplify the relationship permutation text for space, display a few fewer options perhaps.

Aaaaaand I went a little nuts. Here's a quick run at mobile view. Left, middle, right panes, switch between them by swiping.

holy shit this would make the navstrip 10000% more usable on mobile omg.

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)

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!

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.

I went back and forth on that when thinking out the proposal but "eliminate from dropdown but do not delete" would require adding an additional flag and make it harder to implement.

All that said, the little red "X", while common, is not universal, and having it be a "delete" button is fine by me too.

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.

I'm not proposing changing anything about the current Inbox, and have no plans to do so. I'm proposing adding an additional way to access it, to make it more usable for people who use it like I do.

Again, I am proposing no changes to the current Inbox. This is an additional view only. And if people want to make it something that can be enabled/disabled, that's fine too.

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

Also, I'm not wedded to the little X, it's just something commonly used. A button that says "delete" would be acceptable as well. Just less clean.

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

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

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

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

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

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

rough first draft: the simple cleanup

version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

Re: version 2 roughs

thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

no subject

no subject

no subject

no subject

no subject

Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

Re: Do it.

no subject

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

Re: thoughts on a more substantial change

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject