[4790] [Curve] possible Member List improvements

[Sverre]

Some of these points might be down to personal taste, but with a few minor adjustments, I think the Member List could look much better than it currently does.

• Does the useron.gif/useroff.gif image really need its own column? Due to the "Status" header, it takes upp an excessive amount of horizontal space, so if it could be merged with the "Username" column like in ;action=who, that would be a huge advantage.
• The "Website" column looks completely out of place, since it uses a different background colour/class than the surrounding "contact information" columns.
• Due to the different background colour, the user's number of posts and its related statsbar appear as two totally separate items.

Here's a screen shot of the Member List with the suggested changes implemented:



Also, English isn't my native language, but wouldn't "Member List" be a better term than "Members List"? Whether you decide to change this or not, "memberlist" in $txt['mlist_menu_view'] = 'View the memberlist'; should at least be edited to conform with the chosen spelling in $txt['members_list'], and while you're at it, the unnecessary "the" could also be removed from the same text string.

[Antechinus]

The current memberlist is one of my pet hates. The final one will be better.

ETA: although personally I wouldn't go with right aligned for the post count bars. Right aligned always looks forced and unnatural to me with ltr languages.

[Sverre]

The right aligned stat bar certainly wouldn't be my preference either, but it was the best (easiest?) idea I could think of for my quick proof of concept, which wouldn't add complexity to the code. As good as the browsers' built in Developer Tools are there's also a limit to what can reasonably be done with them - at least in my hands...

I also tried a version with the number inside the stat bar, but that simply didn't look good at all, and it also made the bar less useful (than it already is). If the right-border is removed from table.table_grid td, separate columns could be used for number of posts and the stat bar, but I suspect that style is put to good use elsewhere (#mlist table.table_grid td could probably be used to circumvent that though), and wouldn't a single column be more semantically correct as well?

Anyway, here's a mock-up of that version:


I've also played around with various ways to simplify the Email, Website, ICQ, AIM, YIM and MSN columns, and here are the best alternatives I've come up with so far (provided that a select list can be used to sort the results of course):



And my personal favourite:

[Antechinus]

Yes we tried the numbers inside the bars early on but it has significant drawbacks. The select might be worth thinking about, although I was just going to sort some padding so the headings didn't look jammed up their own backsides. Meh. Can play with it on different res and see what works best.

[Sverre]

The big question is if sorting by the various contact methods is even necessary or desirable. The only ones I've ever seen use it is e-mail harvesters...

[Antechinus]

I've used those in an admin capacity.

[Sverre]

Maybe you're the exception that proves the rule, then

[Antechinus]

Well they keep telling me 2.0 is feature-locked, so I think you're stuck with those features. If you're worried about email harvesters you can always disable those columns on your site (or set them to admin view only).

[Sverre]

I'm not too worried about it really. It just struck when I was trying to accommodate the sorting options in my suggestions for an improved layout, that they may not be needed at all.

[Antechinus]

Just between you and me, one of my favourite pastimes is throwing out standard code when I'm making custom themes.

[Antechinus]

Tracking this, just for added entertainment. http://dev.simplemachines.org/mantis/view.php?id=4790

[Trekkie101]

Fixed in 2.1, some improvements made, not all.