7 ms·
Whoever designed this didn't test to see what happens when you click on third row. You can't click most of the windows on the third row because the only spot wh
by swang 14y ago
Whoever designed this didn't test to see what happens when you click on third row. You can't click most of the windows on the third row because the only spot where you can close them (top right corner) is being covered.
- vlasta2 14y agoYes, I too was blocked from further exploring by this bug. Why so much clicking? Wouldn't it be much better if the box with information simply appeared when mouse hovers over the circle?
- duiker101 14y agoI usually do not like mouse hover to popup but at least they should have made the background clickable to hide the popup.
- tripzilch 14y agoHow about just: All the logo-buttons on top. Infoboxes neatly stacked below them (with enough whitespace of course), all of them visible. Button links to the corresponding infobox's fragment identifier. No waiting for animations to finish, no effects, no reducing the scrolling to 2 fps on the average netbook (which made me give up after clicking two buttons, thanks to the position:fixed elements, on 1366x768 you have to scroll to center the infobox vertically, which is pretty hard to do when it moves this clunky), additionally you can just read the infoboxes one by one if you happen to be interested in all of them, and you can even use the browser's built-in find-in-page search to find something specific. All that functionality missed out on, just because they needed to fade the button's border to brownred in the most inefficient manner imaginable. Maybe it's something else, but somewhere there's a zillion of event-listeners firing away at nothing. BTW you can almost get the functionality I described if you switch off CSS and JS and reload the page :) They already used the fragment identifiers, got so far and then made it nearly unusable with some JS effects framework ...
- Cyranix 14y agoI used to think this way too, but the rise of touchscreen devices has meant that hover-based events restrict your audience.
- dllthomas 14y agoSo why not pop up a transient box on hover and a persistent box on click?
- criswell 14y agoThis is tabular data gone awry.
- mfontani 14y agoWas just about to post a screenshot but you beat me to a description of the problem.. Nevermind, http://imgur.com/Mkx6R http://imgur.com/Mkx6R
- tluyben2 14y agoCame here to post ; http://o7.no/PE3S1P http://o7.no/PE3S1P
- nollidge 14y agoDesign pet-peeve: only way to dismiss a modal window is with a tiny, low-contrast X.
- manaskarekar 14y agoSorry to be redundant, but I REALLY want to stress on how annoying this is. A good alternative is to allow user to click elsewhere on the screen (other than the dialog) or press the escape key.
- csours 14y agoThis is expected behavior in a lightbox style application.
- deleted 14y ago[deleted]
- saraid216 14y agoSince starting to work with modals, I've been baking in a keypress captures on ESC into my code to close them. I have yet to actually decide this is a good idea in most cases, though.
- nopassrecover 14y agoEither they've fixed it already or it must be resolution based.
- joeblau 14y agoI see the same problem on my MacBook Air :).
- anonymouz 14y agoI see the same problem: In the third row, the "modal dialog" has its lower boundary aligned with the lower boundary of the third row. The top (containind the 'x' button) is then hidden behind the red banner at the top. Guess: They display the "dialog" either with its lower boundary aligned to the row of icons you click, or with its upper boundary aligned to the row of icons you click (depending on which direction gives more vertical space for the dialag), but if the total vertical resolution is too small, part of the dialog may still be hidden.
- deleted 14y ago[deleted]