Startup 2.5 Beta Ready for Testing

I guess I’m the first to give feedback. Thanks for adding an toggleable Menu link for small sizes (instead of having the whole menu taking up space all the time). But to fully serve touchscreen users, you need to do one more thing (and it should probably be done at all sizes, because of iPads and such): change the way submenus respond to events. Right now only hover will show submenus, and touchscreens cannot hover – they can only click, double-click, and long-press. (There may be other places in the theme where hover is used, but the nav menu it where I noticed the issue.)

I have not personally done the programming for solving this problem, but doing a bit of googling and reading some of the hits, here were a few pages that looked informative:

• http://www.prowebdesign.ro/how-to-deal-with-hover-on-touch-screen-devices/ (except that he didn’t try to detect touchscreen devices, which is the approach I would think most effective)
• http://callmenick.com/2014/03/19/touch-events-instead-click-hover-javascript/ (after I refined my search to look for touchscreen detection)

Another page, although applying it for something else, had this neat little function for detecting a touch screen, without using Modernizr:

function is_touch_device() {
return (('ontouchstart' in window)
      || (navigator.MaxTouchPoints > 0)
      || (navigator.msMaxTouchPoints > 0));
}

I don’t know if it works on all devices, but it looks promising – I like simple.

But then http://jeffschuette.com/2014/01/15/detecting-touch-devices/ is a simple blog post that points out the weaknesses in all current attempts to solve the problem – argh!

Anyway, perhaps some of this information might be helpful to you. Any move toward more support of touchscreens for the nav menu is appreciated.

I’m so sorry! I wasn’t originally testing it on anything, because I don’t own a smartphone. I was simply observing the behavior at small widths and in the Screenfly simulator, and I assumed that if hover worked, tap would not (because I thought it would act like a mouse click, which would open the parent item instead of the sub menu). But my husband does have a smartphone, so after your last post I asked to borrow it and tried it. Amazingly, it does work as you say! Apparently tap on a smartphone (at least on a brand new Galaxy S5) is a distinct event from a click – that’s great.

But one new problem occurs on the real hardware that was okay in the simulator – on the Galaxy S5 (default browser), the little arrow that indicates that a menu item has a submenu is not visible for some reason. There is no visible scrollbar, so that isn’t the cause. Here are screenshots with and without the submenu open.

I noticed another issue with submenus at the mobile size. You reduced the width from 180px to 150px, and that got my attention, because one of my first couple of submenu items is forced to wrap on the mobile screen. When that happens, the line spacing is such that it’s not obvious that it’s a single item.

Take a look at http://thinkword.com/wp-content/uploads/temp/StartupPro-2.5-mobile-submenu.jpg – it is two cropped screenshots of my developing site in Screenfly on the iPhone 3/4 setting. On the left is the current StartUpPro and on the right is version 2.5. Two concerns:

1. Is there a reason why the submenu needs to be that narrow? Yes, some of the main menu need to be accessible on the left of it, but mobiles less than 360px wide are rare these days. Also, a fixed width in pixels makes the submenu a long way over from its parent on mid-size screens (like a 7″ tablet in portrait mode). My suggestion is to use a percentage in the media query – something around 70% looks pretty good to me.
2. When the menu item “Children’s Sunday School” wraps, it’s hard to tell that it is one item. I suggest that the line height be reduced – you are currently using the line height to separate the menu items, but that should be possible with some combination of padding and margins, so that line height can be used for the text itself. I failed in a short attempt to whip up an example, but you know your theme’s CSS better than I do, so you can probably get it to work with no trouble.

Hmm, am I the only beta tester? Anyway, I noticed an unexpected behavior (intended by you or not, I don’t know). When using on mobile, after tapping “Menu” to open the menu, if that’s all one does, the menu stays open until you tap again to close it (that’s what I would expect it to do, since it is a “toggle menu”). But if you then tap an item that has a submenu and the submenu opens, you only have a few quick seconds to decide what to do, or the whole menu will close up on its own! Is that intended? It seems quite inconsistent – the behavior should be the same – either have a timeout or not (I would prefer not, since you still have the toggle button available), but it seems bizarre to have a timeout only if a submenu is open (that affects the whole menu, not just the submenu).

And if you plan to have a timeout at all, I think the time is way too short – I don’t know how many seconds it is, but the person to whom I was showing the site felt rushed looking at only two submenu items – imagine if there were half a dozen or more!