18th March 2015 at 12:26 pm #4136
I’ve been wondering for some time now if kiwitrees should change the way the main menus work. What are your views on this subject. You might want to do some research on the web too. I have done, and it is a complex issue with many different views. But my main concern is what your views are. There certainly is no right or wrong answer.
First, for clarity I am referring ONLY to the main menus (Home, Charts, Lists, Calendar, Reports, etc…), and ONLY to the hover / click functions of menus, not their content, or configuration options, etc.
The current situation:
All themes – open a list of sub-menus when you hover your mouse over the top-level menu item if it has a list of sub-menus.
All themes – if you click on that top-level menu item (like “Charts” it opens a page. This is generally the same page as the first sub-menu item but not always. Charts for example opens the “Pedigree chart” which is the 9th sub-menu item.
- Having a top menu items that includes TWO functions – however AND click doesn’t work on touch devices [tablets and smart phones].To be fair it does sort of work on Apple devices. Touch once to open the sub-menu list, touch a second time to click. But on Android devices this double-touch doesn’t work. The single touch only operates the click function [opens a page] and ignores the hover, so sub-menus are never displayed.
- Some people regard hover menu drop-downs as slower than a click-to-open, and annoying because they open when you simply move past them, not just when you actually want to open it.
- Clearly one option is to do nothing, and leave everything as it is.
- One often recommended modern solution is to abandon hover menus completely. We could easily add an arrow or similar to indicate the existence of sub-menus.
- Another possibility is to make the top-level item hover only. Remove the link to a ‘real’ page unless there is no sub-menu.
SO….. what do you think? Are there other solutions I’ve missed?
18th March 2015 at 5:40 pm #4137
I understand the dilemma as mobile devices become much more common. I do like hover, probably because it’s what I expect will happen happens. As you mention they work on Apple devices and to see, I tried viewing on my iPad. However, I’ve been on sites where hover doesn’t work and it’s frustrating. The iPad version of Safari isn’t like using the desktop version so I feel helpless.
That said, not sure I want hover abandoned. And you certainly don’t want to code “if device = A, then do that, if it equals B, then do this etc, that would be a nightmare. Akin to programming workarounds for MSIE (does that still exist?)
Usually when hover presents a drop down menu, I’ve programmed the click on the button to do nothing. In other words, you must select one of the submenus. Only where there wasn’t one, like HOME. So would concur with your option 3.
[updated: 11 Jun 2021]
MacOS: 10.15.7 (Catalina)
Safari 14.0.3; Firefox 89.0
PHP 7.4 FastCGI
Alter-Drukarsh connections... 3.3.8 <private>
The Royals 3.3.8<royals.rbcsolutions.ca>
The Gerrer Rebbes 3.3.8 <royals.rbcsolutions.ca/index.php?ged=rebbes>
22nd March 2015 at 11:46 pm #4154
My preference is option 1, leave the menus as is. However, the time of the touchscreen and not just tablets is here. To accommodate those users, change is probably necessary.
Of the two remaining options, I prefer option 3 but suspect option 2 will be preferred by the majority of touchscreen users.
A menu change really isn’t a deal breaker for me. I can live with whatever choice is made.
Apache 2.4.27 PHP 7.19 MariaDB 10.2.8
23rd March 2015 at 10:40 am #4161
I don’t have a problem with this the way it is. I use only on a conventional desk top with non-tactile screen, or when travelling on a conventional laptop with non-tactile screen so I may be becoming atypical, but I am used to the hover, then select from drop-down list approach, and like it. None of my users has raised it as an issue or suggested changing so I would favour Option 1.
However, out of interest, as you mentioned smartphones, I just tried accessing my site on my Windows Phone (a large Nokia Lumia with 15cm dia screen – it’s really a ‘phablet’ just about the largest size screen for a smartphone, like the top of the range Samsung). Frankly I can’t imagine anyone seriously trying to do much on a webtrees/kiwitrees site with such a device, let alone with a smaller smartphone and I don’t think much effort should be expended on catering for that usage … BUT … for information, IE on Windows Phone (currently the only browser available on Windows Phone) does not seem to handle the menus as you have described for Android or i-Phone, but as follows:
– touching a menu icon does nothing
– touching it twice only changes the size (zooms in or out)
– holding the finger on the icon has the effect of a hover (produces the drop-down list)
I should add that on menu items like Charts, where there are 13 items in the drop-down list, the list has to be expanded to maximum size (even on the max size smartphone display) before the menu items are large enough to be correctly touched to select, which I found really cumbersome.
But on a general point here, I must try to discourage you from trying to modify too much to cater for smartphone and (at least mini-) tablet use, when they would seem such inappropriate devices for anything more than a very brief consultation of a kiwitrees site. The result could be to the detriment of the ‘normal’ PC user. For a good example of how this can go seriously wrong, you only have to look at Microsoft’s Windows Mail client under Windows 8 which has been designed to work on all devices, apparently with an emphasis on small touch-screens ( on a decent-sized desktop system, the display is ludicrous – huge fonts and extra-large, wasteful spacing between lines over which the user has no control, resulting in frustrating amounts of scrolling – simply to ensure that it is legible on the smallest screen devices which can run Windows!).
Ron in France
kiwitrees 3.3.9; PHP 7.3.5
23rd March 2015 at 11:32 am #4162
Some great thoughts coming here. Thanks for the input.
But on a general point here, I must try to discourage you from trying to modify too much to cater for smartphone and [at least mini-] tablet use, when they would seem such inappropriate devices for anything more than a very brief consultation of a kiwitrees site.
I totally agree with this. IF a mobile solution is required (a very big if) then a custom made app rather than a complicated adoption of a desktop product is the way to go. Much as I hate to say it, ancestry.com have done this well. Their family tree app works well enough on a smartphone, by having only a very limited range of functions available compared to the desktop version. It is a purpose designed app that has very little in common with the desktop version other than the underlying data.
However, I do use an ipad myself extensively these days, and do want to make menus just a little easier to use. Roy also makes a good point that touch-screen devices in general, rather than smartphone / tablet devices are growing in popularity.
Working through the issues I actually think there is an “option 4 – use a different type of menu for smaller screen sizes” not mentioned in my earlier list. It was alluded to by ‘macalter’ in her comment “And you certainly don’t want to code “if device = A, then do that, if it equals B, then do this etc, that would be a nightmare.“. It actually, just for menus, doesn’t need to be a nightmare.
Have a look at my our-families.info site on some other devices and see what you think of the solution now employed there (see also image attached here). It’s is not yet well polished, but does help. I have also actioned option 3 as well.
24th March 2015 at 6:03 am #4172
Have a look at my our-families.info site on some other devices and see what you think of the solution now employed there [see also image attached here]. It’s is not yet well polished, but does help.
I think that’s good Nigel – hover menus retained on larger devices; good practical alternative on smartphone. Point taken.
While checking it out – this is not a menu issue, but you may want the feedback – on the smartphone (at least on Windows Phone) when display held in landscape position, the standard page-footer detail (starting:
For technical support or genealogy questions …
appears enormous – expanding to fill the width of the display and totally dwarfing the main part of the page squeezed in above it, particularly noticeable in Lists-Individuals, Lists -Families, where the main part is hardly visible.
Ron in France
kiwitrees 3.3.9; PHP 7.3.5
24th March 2015 at 7:28 am #4173
While checking it out – this is not a menu issue, but you may want the feedback – on the smartphone (at least on Windows Phone) when display held in landscape position, the standard page-footer detail (starting:For technical support or genealogy questions …) appears enormous – expanding to fill the width of the display and totally dwarfing the main part of the page squeezed in above it, particularly noticeable in Lists-Individuals, Lists -Families, where the main part is hardly visible.
Thanks. Yes I am aware of that, and many other issues. Making the site just viewable on small devices will be a long slow process. Hence my comment ” It’s is not yet well polished…”.
- The topic ‘Your thoughts on menus?’ is closed to new replies.