Love the scalable dashboards as they offer more flexibility on rendering.
However, one of the limitations for just ‘button’ based dashboards is that one needs to create a separate dashboard for each device metric one uses. This is a slightly different problem from the reflowing dashboards which also needed a fixed pixel size definition.
Consider the best of both worlds: Dynamically reflowing scalable dashboards (TM pending )
Ability to specify dynamically in the URL itself, how many columns should the dashboard render at run-time.
For example consider the dashboard example screenshots currently set as scalable and 4 columns to fit a portrait average iPhone (not the Mini and not the Max):
On the iphone it shows great. If I load it up on my breakfast ipad (which is landscape), buttons are huge and screen only fits a few. If I load it up on my Mac chrome, even bigger and not very usable.
However, if I specified in the URL for the iPhone something like: SharpTools App** it would show nicely
and if I took the parameter to ?columns=8 - it would render perfectly on my iPad Mini
and if I took it to 10 then it would show nicely on my regular iPad
and perhaps 12 or 14 would look good on my Mac
yes, it starts sounding and looking like the reflowing version but even the reflowing is fixed pixels (perhaps consider ?tile_size=120px as an alternative parameter that can be handed over at run-time?
and if we wanted to get fancy, the parameter can be generated from a property or set of properties on the dashboard management screen as attributes and it would still be much easier than maintaining many separate versions of the same dashboard on a per device basis.
Thoughts?
How a scalable dashboard looks on my iPhone:
A general community “Elections ”: I just noticed there is a quota on casting votes when I just voted on features requests including this one… Is this number allocation that increases over time or is it a finite number of votes each user can ever cast?
The vote limits are based on your ‘Trust Level’ in the community. The more you engage on the community, the higher your community Trust Level and the more votes you get.
After a Feature Request that you voted on is closed, the vote gets returned to you so you can cast it somewhere else.
At any point in time, you can also Unvote on something you’ve voted on which frees up the vote to be used elsewhere. (See ‘My Votes’)
Gotta use my last vote on this one, as I’m having a devil of a time figuring out how to view my dashboards on multiple screen sizes without creating copies of each dashboard (easy), and then new tiles for all the dashboard crosslinks (PITA). With each new dashboard I create, the number of linking tiles that have to be re-created goes up exponentially.
The way I read this request is the current Dashboard Settings let you adjust the tile size (120px) or columns (8), but it’s a fixed setting. This request is to let you change that tile size or column count setting based on the URL.
It sounds like your issue is that you want to have the dashboards stay the same, but just change out the navigation tiles for the crosslinks?
Correct. Being able to specify the number of columns or size dynamically at the URL level would allow to have dashboards that size them selves based on user preference for the form factor and screen size vs. creating multiple dashboards, each for every screen size as per the example scressnshots I supplied at the top of this request.
Consider the number of columns fixed-size on a portrait vs. landscape orientation of a tablet or on a tablet and a phone and a desktop - much more efficient than creating several versions of the same dashboard due to the sizing being fixed at design time vs. being able to be specified at run-time…
I believe that what @calansvc is referring to is that if you link from dashboard1 in a certain form factor to dashboard2 of same form factor and need to produce several distinct dashboards for each form factor then the links would indeed grow exponentially as in:
dashboard1_iphone_portrait —> dashboard2_iphone_portrait
dashboard1_iphone_landscape —> dashboard2_iphone_landscape
dashboard1_iPad_landscape —> dashboard2_ipad_landscape
… and so on and so on which becomes unwieldly.
)
”: I just noticed there is a quota on casting votes when I just voted on features requests including this one… Is this number allocation that increases over time or is it a finite number of votes each user can ever cast?
