 | Kirill Bondar 10/14/2014 5:08:03 AM
|
 | basenine 7/13/2016 12:40:59 AM Is this still on the radar?
|
| basenine 7/13/2016 12:44:58 AM Perhaps also add to this: responsive graphs please.
😃
I used this code to make an embedded youtube video responsive:
<style>.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 70%; height: 70%; }
|
| Kirill Bondar 7/13/2016 4:25:23 AM Still on the radar, but we have no solution for a scenario when there are two tables in a row and one table's width exceeds half of the available width. It's cropped, we want it visible.
|
| basenine 7/13/2016 6:12:12 AM How about doing a "pop out" window (like selection record pop out for related records) when you press the (cropped/shortened) view. In fact, all views on a mobile device might benefit from that(?)
|
| Kirill Bondar 1/27/2017 6:03:13 AM Now available under labs.
If both views in 2-column layout fit to 50% width, layout is identical to non-responsive dashboard. If one of the views exceeds 50% width, both views start to occupy full row. Charts are also adjusted to fit the width of their container if their default width exceeds that.
|
| Kirill Bondar 1/27/2017 10:22:59 AM As we only downscale charts, you may want to adjust charts' width/height from Normal/Normal to Wide/Tall for best results.
|
| Kirill Bondar 1/31/2017 7:55:17 AM Added support for macOS/iOS Safari and IE11
|
 | Philipp Matuschka (MMB) 2/2/2017 4:15:14 AM I've tried this out this morning and found that I would like to be able to set different behavior depending on device type. In particular, I do not want the new responsive mode on my desktop (makes the display very jumpy), but I definitely do want it on my mobile device type.
Suggestion: make this selectable by device type.
|
| Philipp Matuschka (MMB) 2/2/2017 4:15:58 AM By the way, I have turned it off again because it was so distracting on full screen.
|
| Kirill Bondar 2/2/2017 6:29:38 AM @Philipp: could you please send us some screenshots or describe a scenario you are using? The idea behind responsive dashboard is to auto-switch to one-view-per row if two-in-a-row do not fit but we never noticed views are jumping between two possible layouts.
|
 | Scott Miller 2/2/2017 8:12:07 AM @Kirill: using an iPad the Headline and Charts now fit the screen which is great. What i did notice (I think this has always been the case) is that when you scroll up and down the screen shake around the tabs and View header columns is quite considerable. They take a while to stabilise as they appear to float. Not sure if this is the same issue that @Phillip is describing although this is just on the iPad not desktop. Just to add my eyes were tested yesterday :-)
Mr Magoo
|
| Kirill Bondar 2/2/2017 9:59:24 AM @Scott, this is a different problem. To make headers scroll we listen to scroll notification. Desktop sends scroll notification on every move, in contrast, mobile browsers send notification when page movement is fully stopped - to save battery life by avoiding code execution. Thus there is a delay before headers stick to top position and move from top position back into their original placement. There is a tech to instruct browser to scroll headers automatically, but so far it is not cross-browser compatible.
|
| Philipp Matuschka (MMB) 2/3/2017 6:05:04 AM Kirill
I have a dashboard with two charts side by side and a text view below that. If the text is too small when initially displayed, I zoom in. This makes the charts appear in one row each, but the text has now "jumped" off the screen. I suspect that this is exactly what you were aiming to achieve, but I find the user experience unpleasant.
I'll put the screenshot into a support case as it contains live data.
On the other hand on a mobile device, the effect now is that that two charts are always on one line each, so no sideways scrolling required, which is very agreeable.
Thus the suggestion to make this configurable by device type - Browser()
|
| Kirill Bondar 2/3/2017 8:07:39 AM @Philipp: oh, zoom!
Since IE7 times browsers no longer blindly upscale page's picture rather increase font and element sizes and let the page update the layout. From page's perspective upscaling is reducing its size so that 1024px wide page at 200% zoom thinks it's 512px wide. In case of TeamDesk upscaling puts extra tabs into dropdown, form updates the layout forcing 4-column form to layout in 2 columns then to 1 column and finally forcing labels on top. In this case dashboard behavior is consistent with its surrounding - since chart does not fit it is moved to the bottom - to avoid sideways scrolling.
For the times we introduced Browser() function it had sense but now - with the blurred lines between device types - besides adopting form behaviors for email notifications it has no sense at all. Is 13.5" Microsoft Surface notebook with detachable touchscreen a "Desktop" or "Tablet"? Is Samsung Galaxy 6.3" phone a "Mobile" or a "Tablet"? Is Smart TV a "Desktop" if it has keyboard and mouse attached? What if not? Should we consider iPad running Safari in a split-screen mode a "Phone"?
|
| Philipp Matuschka (MMB) 2/3/2017 8:41:24 AM Ah. Shrink not Zoom!!
Still finding the same annoying behavior when shrinking. But I can better understand the thinking.
You ask: Is 13.5" Microsoft Surface notebook with detachable touchscreen a "Desktop" or "Tablet"? Is Samsung Galaxy 6.3" phone a "Mobile" or a "Tablet"? Is Smart TV a "Desktop" if it has keyboard and mouse attached? What if not? Should we consider iPad running Safari in a split-screen mode a "Phone"?
Surely this is not up to you to decide. If I read the documentation of the Browser() function correctly, you are simply passing on information from the user-agent string sent with each request. It should therefore be fair to assume that each device knows what it is and passes through that information to you and you make available to us via Browser().
Maybe another way to solve my concern it is to make it configurable as a user preference in Edit preferences.
Or maybe I'm the only one with the concern, in which case I will shut up.
|
| Kirill Bondar 2/3/2017 9:41:14 AM @Philipp: In 2012 we planned to use Browser() to determine devices with or without touch interface: touch enabled interface should provide bigger clickable areas and should not rely on pointer hovering above the element; and for screen size (Phone > Tablet > Desktop > TV), but in 2017 these assumptions are no longer true: some tablets have higher resolution than laptops/desktops, laptops have touch screens and with multitasking supported by phones/tables classification by screen size is not of any help either.
> is to make it configurable as a user preference in Edit preferences
Preferences are shared on all of your devices, but I guess you will want to opt-out of responsive behavior on your desktop but keep it on your phone.
Anyway so far we only collect feedback and have couple of ideas to improve charts and including their side-by-side appearance.
|
| Philipp Matuschka (MMB) 2/3/2017 9:50:50 AM Thanks. Just take my comments as part of the comments. I'll be watching out for what comes next
|
 | Philipp Matuschka 2/15/2017 1:54:00 AM I noticed today that where the first column is text and the second column is a chart it seems to extend the text to the "maximum" and so the second column always ends up being a second row. Doesn't look great on full screen.
|
