Skip to main content ↑ ↓
Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes Started by emanuele · · Read 23354 times 0 Members and 2 Guests are viewing this topic. previous topic - next topic - Topic derived from ElkArte 1.0 Release Candidate...

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #30 –

The CSS is half-finished?
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #31 –

The template works (at least I haven't see anything badly broken since a while).

If you think it requires work, and want to do it, feel free.
Otherwise wait until it fixes by itself is not feasible, and I prefer to release a theme that works but can be improved, rather than wait years for someone with the knowledge and the will that arrives and says "okay I'm teh man".
The CSS is no different from the code: the current code is not perfect, in many places is not even nice to read, but it works and is in a state good enough for a 1.0 release. In 1.1 will be improved. In 1.2 (or 2.0) will be improved further.

ETA: of course that's only my opinion, if you (all) think it's better to wait and wait until everything is perfect... well I can always for ElkArte. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #32 –

Ok. SMF RC FTW. :P
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #33 –

Not really, to me it can even go "stable" in that conditions.
As long as it works it's fine.
Bugs creator.
Features destroyer.
Template killer.

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #34 –

Yeah I wasn't all that serious. It's nowhere near as rough as 2.0.x RC1 (or even 2.0.x RC2). As I've threatened, I should have time to do a bit of polishing this month anyway. It all basically works but some of the CSS could be better organised, just to keep up with the "make theming easier for peeps" plan.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #35 –

Oh, serious suggestion here: at the moment the menu suystem defaults to hover, with click only available for logged-in members.

This is not good for guests on touchscreen, who realistically will make up a significant proportion of anyone using an Elk site. It's a bit silly feeding people a responsive and mobile-capable theme, but with a menu system that is tailored for operation with a mouse.

The current setup is a relic from the days before touchscreen was important. It came about via CSS-only drops being added to 2.0.x, then Superfish being added to 2.1 Alpha, then Superclick being finally added to Elk, with the result that Superclick was the "afterthought".

Gvien the whole mobile-first emphasis these days, it would be better to make the menu system default to click/tap operation, with hover being selectable for logged-in members that want it.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #36 –

I'd like to have the ability to have a dark variant including editor theming before it goes RC, Final, Happy, whatever.  But I guess if going to that next state of readiness means code changes should slow down I'm fine with just hacking up the code to work.

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #37 –

Oh I thought the dark variant shiz was being sorted. If not, then that defo should be done before RC. That's a pretty major oversight.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #38 –

I think there's a commit for the wysiwyg portion being handed off to the sceditor class (although it was hard coded to the default theme instead of using the current_theme variable available :( )  but custom.css go moved up to load before various other css scripts like some whoxxx.js and for the editor jquery.sceditor.css that loads all the styling for the non-wysiwyg parts of the editor like the normal text edit box and the bbc buttons.  So a variant can't restyle that now.

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #39 –

Makes no sense to promote a variant system for styling stuffz if a major component of the interface cannot be styled via the variant system. Logic 101.

This should be a called a blocker. If it gets called a blocker, someone will get motivated to fix it. ;)
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #40 –

Hover vs click. Obviously click by default is bad on desktop browsers. Just enable it on (window.touch) browsers that aren't logged in.

Or alternatively rewrite your menu code. Wedge for instance works for mobile with clicks without the need to add a silly library. Its almost 100% css3 code.

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #41 –

Quote from: Nao – Hover vs click. Obviously click by default is bad on desktop browsers.
There's nothing "obviously" about it. I prefer click on desktop.

ETA: I should explain that a bit. The advantage of click is that I can get a menu exactly wheh I want it, and never get a menu when I don't want it.

Hover is a nusiance if the gui is heavily reliant on droppies. They will sometimes trigger accidentally, even with hoverIntent, which is annoying and can slow down use of the interface. This is particularly true if you are trying to provide good accessibilty for the droppies (as you should) .

Among other things, good accessibility requires a significant mouseout delay. Note the use of the word "significant". The whole point of having the mouseout delay is to help people who have poor tracking skills, and/or less than perfect reactions. What has happened with the current Elk droppies is that the mouseout delay has been reduced, to try and mitigate the problems with opened droppies getting in the way. It has been reduced to an extent that effectively makes it useless to the people it is intended to help.

If you use click (with click anywhere to instantly close) there are no problems with accidental opening or with lingering opened droppies. You also don't need hoverIntent, which means you can open a menu faster even though it requires a click. Yes, it's true: click menus are not slower to use. They are just more controllable and less likely to cause problems.
Last Edit: April 05, 2014, 06:08:53 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #42 –

You make a valid point, but my analysis is also based on usability.
I'd gathered that the timeout should be at around 250ms: enough to allow 'clumsy' users to move their pointer back to the menu if they got lost, and also short enough not to get in the way if the menu was triggered involuntarily.

Now, here's the trick: when I started playing with CSS animations (up until a few months ago, Wedge had been using JS animations for menu timeouts), I realized that once you started an animation, *the hover effect was valid until the animation was finished*. That is, if the timeout animation was running, you could STILL move your mouse back to the menu area, and it would stop the animation, and proceed to bring back the menu. Not only does this look cool, but it also solved many of my problems when I was using JS animations -- most notably, I was able to get rid of all JS to control timeouts, because CSS3 was now handling that for me...!
And believe me, I'll never look back. It's just... Natural. And it works fine on mobile, as long as you don't forget that Android devices tend to disregard a submenu being opened if its parent item has a clickable link. You just need to disable the clicking for these, and you're done. SMF menus always offered a 'copy' of the parent links inside their submenus, so this isn't even a problem for usability.

Best of both worlds, really... 8)

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #43 –

Quote from: Nao – You make a valid point, but my analysis is also based on usability.
I'd gathered that the timeout should be at around 250ms: enough to allow 'clumsy' users to move their pointer back to the menu if they got lost, and also short enough not to get in the way if the menu was triggered involuntarily.
And here's your first mistake. Average human reaction time is around 0.25 seconds. To set a mouseout delay that will be useful to people who need it, you have to use a value that not only allows for average reaction time (at an absolute minimum) but also allows getting back to the menu. 0.25 seconds is simply not enough. More suitable values are in the 0.5 to 0.7 second range.

So now you'll say "But at those values, opened menus will get in the way". I know. That's what I've been telling you. If you pick a reasonable value for a11y, as opposed to just picking a value that will hide menus fast because you want to hide menus fast, you get problems.

As for the rest, from an a11y perpsective it doesn't really matter if you're using js or CSS to control the thing. The advantage of js was support for IE8. That will be less significant in future versions.

ETA: Oh, the other problem with pure CSS, assuming you are using a mouseout delay that is long enough to be useful, is when you open the wrong menu in a complex area like admin or profile, then have to go find the right one. You can quickly end up with a mess of opened menus if they are all triggered by hover.

Javascript was invented to control behaviour. It's good at that. Sometimes it's worth using.
Last Edit: April 06, 2014, 04:00:27 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Grumbling about bugs - Was: [WIP] ElkArte 1.0 Release Candidate 1 - release notes

Reply #44 –

My main menu was done 50% CSS 50% JS back in the day. Actually, I learned JavaScript in order to write that menu. I was very proud of it. I even force-pushed it into Aeva Media 2.10, even though it was most useless in there (too few menu entries to show!).
The fact that I managed to turn it into 100% CSS while actually improving usability is a bonus for me.

Of course, usability != accessibility. And I'm not talking about accessibility here. I try to keep my code accessible, but if I truly wanted to make Wedge accessible, I wouldn't be using menus, because even a click-to-open menu requires some targeting, which disabled users might not be comfortable with.

You've got to draw a line and determine whether you want your software to be "reasonably X, and great at Y", or "great at X, and reasonably Y". It always trumps being "perfect at X/Y, and very bad at Y/X".