Subtle changes, bugs and feedback

I would have had it, but I had to modify the cache setting for LFGSS in Opera to make it even halfway usable. Then I had to open FF (and go through the fucking Persona bullshit log in yet again) to upload the attachments, as neither drag-and-drop nor clicking on "Upload a file" has any effect in Opera.

I noticed the first-previous-next-last buttons are at the top of threads on mobile now, which I approve of... They still seem to be missing from "following"?

And forums.

On that subject, I wouldn't mind a first-previous-next-last navigation on the desktop in preference to the page numbers.

All of the chat about "fonts are better if they're big!" seems to centre around what's best for articles and blog posts, rather than what's best for a collection of (often very short) comments from multiple people who are taking part in a conversation, sometimes with each other and sometimes around each other. I still haven't seen any genuinely convincing arguments in that respect - people just don't sit down and read forums in the same way that they'll read magazine articles or books.

Basically, people have gotten very used to reading terribly-typeset text in all sorts of media and contexts, and filtering out the noise and clutter. (In the 1950s people used to complain about paper being too white to read comfortably outdoors, for example.)

Teeny tiny text is fine for a lot of people (power user types like us who spend all day using computers/smartphones/tablets) but there really are a very large number of people – e.g. with less than optimal eyesight – for whom larger text in shorter lines is immediately more comfortable and natural, and those people may also not be tech-savvy and not know how to increase the text size.

FWIW I think I preferred the even-larger text that Microcosm-LFGSS launched with.

I like the new 50 post pages and external links launching in a new tab.

Teeny tiny text is fine for a lot of people...but there really are a very large number of people – e.g. with less than optimal eyesight – for whom larger text in shorter lines is immediately more comfortable and natural

This seems to be a good argument for the restoration of the old 'font size' buttons which got binned in the mad dash to make LFGSS look like everything else.

This seems to be a good argument for the restoration of the old 'font size' buttons which got binned in the mad dash to make LFGSS look like everything else.

I tend to agree. Browser size controls can work in different ways (some change the size of elements and images etc. as well, some don't) and you might not want to change every site, and you might want it to remember different settings for different sites. If you're controlling the changes to the style sheets on a per-site basis it's probably easier to manage & predict how the layout adjusts and it's probably more friendly to many users, if much less 'best practice'.

Making that setting clear and obvious, wherever it is, is probably the most important thing. In the course of testing websites and apps and so on I see far more people that have increased the default text size on their iPhones than on their desktop web browser (that may be down to the inevitably even-teeny-tinier text on a phone making it more necessary of course). But that notwithstanding, a larger default text size makes sense for a lot of users, probably the majority of users.

It's WWW growing pains really. If everything was nicely responsive and everyone knew how to use the browser size adjustment then all would be sparkles and rainbows. I do sympathise with the efforts being made to get to that point. There's a similar issue on the horizon with resolution-independent sizing. That going to be interesting/painful.

The description of this terrible font as "highly readable" amuses me.
It might be on a retina screen but it's frightful on an iPad 2.
Tiny squished up letterforms, low x-height, low letter spacing, poor hinting (which is better on the smaller size than the original, granted). Really to claim everything else is done in the name of legibility and then to ignore all the screen-optimised fonts in favour of this thing is baffling.

(And yes, I do have an up to date prescription in my glasses.)

In fact the tiny "Bold , Italics, Link..." Etc buttons in the edit box are clearer and easier to read than this text I'm writing below them.

Do agree. It's not a very good screen font. Even with higher resolutions today there's still a large variation in how fonts are rendering cross-browser and serif fonts seem to come off much worse than well-hinted sans-serifs. Some are just awful.

Its lovely on my phone, and i was here begore you and I bar spin, so fuck the lot of you.

#lfgssstyleeee

@BlueQuinn
Font looks fine on my iPhone4, in safari. Wondering how much this battle of the fonts/legibility is an actual desire to produce something better or a need to be proved right?

I have none of the technical typographical knowledge being sucked out of the ether here, but the question becomes do you break the essence of something to please a vocal few? Or let it annoy them admit doesn't upset/ and is possibly a better experience for the silent majority.

On that subject, I wouldn't mind a first-previous-next-last navigation on the desktop in preference to the page numbers.

The exact opposite is going to happen.

Currently pagination on mobile has to take up two rows as there isn't the space in one row for the full options: Page [x] of Y [First|n-1|n|n+1|Last]

Just showing "First", "Prev", "Next", "Last" without context and information as to how many pages remain, how to get to another page outside of that sequence, is pretty bad. Not least because what on earth is "Prev"? Maybe it should be "Prior" or "Back", but "Back" has meaning within web browsers, "Prior" implies "Back", ugh.

So I've been thinking of moving the pagination form into the pagination control on mobile: [First|n-1|[x]|n+1|Last]

It's tight, shows the current page, allows you to jump to another, is more consistent between desktop and tablet and mobile. It doesn't communicate how many pages there are if you're not at the end, but it does give you info about which page you are on and you can still binary chop your way backwards.

This looks good in testing, so may go live today.

Your queries must have been a bit messed up as I searched by author all of the time (I'd forget where somebody posted something but remembered who posted it)

EDIT: By 'all of the time' I clearly meant 'once in a while'

Consistent between mobile & desktop version isn't a good goal - benefit from both systems specialties is.

Greyed out first if on first page or last if on last page (rather than removing the buttonlink) would go a bit toward helping usability.

Your queries must have been a bit messed up as I searched by author all of the time (I'd forget where somebody posted something but remembered who posted it)

EDIT: By 'all of the time' I clearly meant 'once in a while'

I specifically qualified my statement by pointing our that vBulletin cached the queries, and it was the cache I looked at.

Out of the ~15,000 queries that were cached, none were for an author search.

That doesn't mean no-one ever did an author search, it only means: in the cache, representing a few days of query, there were no searches by author.

So whilst they do happen, there are extremely rare relative to all other kinds of search.

Given that information... is this the highest priority work I could be doing when the means to perform the search exists already? My conclusion, no. Other real bugs and issues do exist that are directly impacting some people, those take priority.

Which font are you talking about? I don't think microcosm uses downloadable fonts does it? It relies on a list of fonts that you may have on your computer. Maybe if you have 'elena-web' it looks rad.

Consistent between mobile & desktop version isn't a good goal - benefit from both systems specialties is.

Would mobile users be fine with not being able to jump to any page of choice?

I could certainly solve this by removing that altogether.

But if I want to offer mobile users the means to get to any page in a paginated set, then I'm going to have to combine that functionality with the nav buttons somehow.

Greyed out first if on first page or last if on last page (rather than removing the buttonlink) would go a bit toward helping usability.

To add a button that doesn't greatly differ from the others, consumes space, but does nothing whatsoever... is an improvement?

I think when I've built the ignore function I shall test it on this conversation first.

To add a button that doesn't greatly differ from the others, consumes space, but does nothing whatsoever... is an improvement?

Yes. You are not adding a button you are leaving a button there that is on the other pages. Stability in UIs is best and greyed out buttons help users easily understand what is going on without having to think about it.*

* "thinking about it" for basic UI tasks is usually interpreted as usability problems

/me Awaits 'getting ignored by bossman'.

That's one school of thought.

Another is to simplify interfaces by removing that which you cannot do, to not confuse users by offering options that are not available to them (in whatever the current context is).

It's the difference between a menu that says "These are choices you can make right now", and one that says "These are all the possible choices, but some of them are not available to you right now".

But anyway... I have work to do.

Valid arguments both ways. Cue dogma war. Or just let VB pick one option and go with it. Bigger fish to fry.

Shit, if I keep this up VB is going to start thinking I am a sycophant who fancies him.

#livesinhope