Which other methods of categorizing styles can you think of?

[denise]

I've just migrated Bug 3883: Add an Optimized-for-small-screens category to the Select Journal Style page and am opening a bug for additional other categories:

* optimized for large fonts
* high contrast
* low contrast
* streamlined/minimal distractions

What other categories can you think of that you would want to see? I'm mostly interested in things that are accessibility-needs related, but if you can think of other ways to categorize, I'd like to know.

Comments

[zvi]

* Color
* Includes images

[musyc]

*Customized navbar (I dislike those immensely, some love them.)
*Default main column width (not everyone knows that's something that can be changed, even with sidebar/module switcheroos)


What I would like to see is an example of each base-as-designed layout actually on a journal, really. There's been a number of times that I thought a layout looked awesome until I tested it and realized it changes all the italics to colors or the icons have an opacity or something like that. A live preview with the base layouts would be fantastic for avoiding those sudden curiosities.

[ex_rising236]

Yeah, I've had problems with the italics-to-colours thing to, and such, or that the whitespace between lines was a little too much for me to actually read it easily. It is what got me into the more finicky parts of custom CSS overall.

[musyc]

Hahahaha, exactly. "This layout is awesome, but why is my bolding pink, auuuuugh?" The number of times I've had to baby-step a friend through tweaking one line because of a designer's decorations over the past decade. *flump*

[zvi]

As an interim categorizing measure, we could create a category for "changes text styles in non-default ways".

[jesse_the_k]

ZOMG that is the right name for the category and would be very helpful. (For values of standard = DW light, of course.)

[yvi]

Clicking on the upper right corner of the preview picture (the magnifying glass) should open a window with your own journal in that style. You can even browse around to the other views (tags, archive, etc.)

[musyc]

Yes, I'm quite aware of that. However, if I haven't set up an entry with examples of text, or if I subscribe to a journal later that (for example) uses a lot of blockquotes, I have no way of seeing what the layout would do until it happens. I'm savvy enough to strip out the CSS that makes things odd for me, and to set up a test journal with short titles, long titles, no titles, square icons, uneven icons, bold, strike, italic, and so on and on, to test for odd things. Most people aren't, and the average journal user never even thinks of that. Live previews, set up with concrete examples of "here's a blockquote in an entry", "this is what italicized text does", etc. are more than helpful for the non-savvy user.

[kerravonsen]

Ah, I see. Yes, that makes sense.

[busaikko]

As an example, WordPress.org has a sample journal page that you can see for every theme (it pops up if you click preview, for example here). It includes tags, links, ordered and unordered lists, blockquote, and so on.

[deborah]

I was wondering if there can be a category for "uses default system text" although we don't have a single default, do we? Because for me, all the words are visible and standard is a huge accessibility win.

[zvi]

Which styles use a text other than the system default? Or are you talking about text vs. icons?

[deborah]

Text versus icons is definitely an issue, because for me text is way better. So I do want them to be categorized as "all the key links are text, not icons." (I don't mind the presence of images, but I do prefer it if tracks/delete/tag etc. are all in text.)

But also, hrm. I guess what I'm thinking of is less an issue with the style I would choose and more an issue with styles other people choose-- I can wish all I wanted there were styles that didn't allow people to change the system text, but people can then just use other styles. That's what style=mine and the like are for.

That being said, there are styles that use different text by default. Zesty seems to use different text for the key site navigation (e.g. reading page/archive). And there seem to be two core variants for the entry icons, cf. skittish dreams versus Sunday morning.

[foxfirefey]

Zesty is S2 core2's, uh, awkward special exception--It wasn't really standardized like the rest of everything and I think someday it should be replaced with a more up-to-date version! I mean, it doesn't even support Custom CSS or any color changes.

[foxfirefey]

Just for reference, property lists I made for layouts and themes are here in the expandable filter section:

http://styles.memewidth.org/layouts/
http://styles.memewidth.org/themes/

[tyger]

Those are fantastic, and where I go now if I want to choose a new layout for anything!

[jesse_the_k]

Wow! That's so much easier to navigate than the current public system!

[foxfirefey]

It's an experimental prototype. There's a bug open to try and implement one more like it on the site itself.

[lanterne_rouee]

That is awesome. Thank you so much for sharing the links!

[foxfirefey]

Of course, now I'm behind with the 99 new themes from the last push!

[lanterne_rouee]

XD Slacker! (Seriously, you're amazing.)

[susanreads]

How does it handle links? I want the links in entry content to be underlined (and also distinguishable colours, but we can customize that in the wizard); a lot of styles lose the underline, or it depends on the active state of the link. On some sites, so probably in some styles, the font changes e.g. to bold when you mouse-over a link, which annoys me and must be an accessibility concern for some people.

[jesse_the_k]

As always, it depends. I find the underline decrease readability, and I kludge them away with an !important statement when they're present.

[lapillus]

Maybe ones that use a fixed width for display? I know that was one of the things I was looking to replicate when I moved here from LJ.

[zvi]

We have fixed width styles? We used to be 100% fluid.

[lapillus]

We may not have any. But it a fixed maximum width for the reading area was one thing that I looked for (and didn't find). The fully fluid means that you you have a choice of reading long blocks of text in something that is significantly wider than is optimal (usually thought to be 60-80 characters) for easy reading or resizing your window. As someone who prefers keeping her browser maximized in a largish monitor this is a big annoyance when reading fic.

[ninetydegrees]

I don't think a fixed maximum width will ever be implemented because it wouldn't work for all users (80 characters in a 12px font doesn't take the same space as 80 characters in a 20px font so what value should you use?). Now that could be implemented as an option but that was kind of the point of implementing the side margins option, I think. I would actually love if we had a 'reading/article view' a little more elaborate than the light view with settings for margins, font sizes, leading, text and bkg colors.

[zvi]

If we implemented max width in ems, would that help?

[ninetydegrees]

It would but only to some extent. Implementing a max width to entries generally means that you get scrollbars because you always have images, videos, code and you have to do something with the overflow (cut it or scrollbar it and both options suck).

[twisted_times]

What is the definition of "small screens" for the purposes of the bug above?

Perhaps there should be different options for each "Optimised for Foo x Bar screen size" category?

[jeshyr]

Do we have any layouts that are not keyboard friendly with indicating active links etc? because if so we need a category for keyboard users - but I am fairly sure they are all good with this.

[sevillana]

Definitely color. I'm part colorblind, and unless the color scheme is named in the layout name, I typically have to ask someone what the colors are.