Deciding what resolution to design for is a common question. For the last several years the general recommendation had been to design for 1024 x 768, which had been the dominant resolution on the web. Now things have shifted. The dominant resolution for the past few years has been (and is) 1366 x 768. This is largely because more and more people are using laptops. So the simple answer is to just say "design for 1366 x 768." That said it's a bit more complicated than that.
Go wide
The trend over the past few years has definitely been to take advantage of the larger resolutions and to start designing wider going beyond the pixel dimensions of the 960 grid system used to design for 1024 x 768. As an example of this trend we can examine the web traffic coming to Qlik.com. I know that the top 8 resolutions are all wider than 1024 which accounted for 78.01 % of our traffic last year. Of those resolutions 1366 x 768 was number 1 with 25.92% of traffic and the narrowest resolution of the top 8 was 1280 x 800. Now there could be certain biases in these numbers, that the people interested in a BI product might be more technologically savvy so they may have higher resolutions than the average internet user, but if you are looking to design apps for BI users then it's a good measurement of your potential user base.
So why consider 1024 x 768
While 1024 is going away it's aspect ratio is still valuable. 1024 x 768 is the same aspect ratio as 2048 x 1536, the resolution of the ipad. The ipad is by far the dominant device in the tablet market. So designing for 1024 means you are going to produce something that the majority of your users can see (since most people are on even wider desktop computers) but also you will have a good idea of what your users will experience when using your design on an ipad in landscape orientation. Designing for 1024 means you can create something once and deploy it on desktops as well as tablets knowing it will be accessible on the devices most people want to explore BI on. This saves you time & resources from having to build things twice, once for wider desktops and again for tablets.
Responsive Design & Dynamic Grids
If you are creating a mashup app, using HTML & Qlik together, then the best approach is in using a dynamic grid that is responsive to the available resolution. It can still be a 12 column grid system but it will adapt based on the device you are using. This approach takes more work but it is the best recommendation for designing for today's web and the realities of people using multiple devices to access the same content. In addition, Google recently announced that "mobile-friendliness" will be used as a ranking signal when they deliver search results. In other words, if your content isn't optimized for mobile devices you may be further down the search results than before. Something to consider if you want your content to be found online.
Listen to your users
Ultimately you are designing for your users. If you are creating an app for an environment where most users are at a certain resolution size, then design for that size. If you are designing an app where tablet usage is likely, consider designing for 1024 or using a dynamic grid if the app is a mashup. If not start thinking about going wide.
Yes to 1024x768 - much as I hate to leave space empty, many projectors are still not wide-screen, at least over in this part of the world. More savvy users have learned to use the extra space on their widescreen by inserting personal objects. Of course, there's the endless problem of actual available space (size of people's start bar, whether the status bar is on, how much of the browser space is being eaten up by different things, etc), but you can't win them all - when 1024-768 just doesn't cut it, I go 1280x800. That still fits the majority of devices and monitor resolutions.
Good insights from both the blogger and first commenter. I sort of fell into this job and am learning on the fly. Listening to end users is pretty much all I do, but always on the lookout for unexpressed wants/needs or pain points they might not want to trouble others about. Most notable is the massive difference in real estate from working on my monitor to undocking the laptop to demo something in a meeting.
Biggest challenge for me is trying to keep things to one screen when people are asking me to chuck in more and more columns (or graphs or other things). Specific guidance on target resolutions for consistency was welcome, and I have horizontal scrollbars for the compromise when # of fields desired grows.. and grows...
That is indeed a major problem - and it does get worse over time as more requests come in.
A handful of things you can try and do:
1) Switch from listbox to multibox to save monitor real estate; use the Search object instead of listboxes where possible. (where you have a long list and everyone just text-searches it anyway).
2) User-created objects or User-toggle objects - you can create the objects and allow users to toggle them on with a "I have a wide screen" button using the Visible condition. 3) Linked objects - a more extreme version of #2, you can create sheets for widescreen that are entirely separate from the 1024x768 sheets (linked objects means you won't have to do *too* much work designing each sheet). Again, these would toggle based on user selection with a button (I would avoid trying to do it automatically based on the resolution, since projectors can mess with that).
There may be others, but those are the ones I've used successfully.
User toggled objects is a clever one to keep some flexibility in an otherwise locked/secured dashboard environment too. Thanks!
I had to disallow users creating objects because it gave access to a repository with objects containing data outside the sheets they were cleared for.. The sheets themselves have whitelists and only show to osusers who are on the list for a given sheet. So some users only see 2 sheets, others see many various sheets, and I see all 30. Also source control on the qvw and accesspoint filtered by that so only people who can use the dashboard can even see it. It's good for security and from a design perspective, the users appreciate only having to navigate sheets and dashboards they actually need. It cuts flexibility a bit, but reduces strain on the server too (the repository is massive). User toggled objects is a nice way to bring back some flexibility.
Edit: Funny one about the search box is we have one dashboard where people talk one-one with callers and only use a search object to look up the caller info. I had to add a table box with lists of people at the client companies in case the caller happened to be 'Joe Smith' and he didn't know the member id # he had with our company. Our person could look up Joe Smith, see a list of Joe Smiths, and ask this Joe Smith to confirm a variety of other info. Then click on the corresponding member id in the table, to be sure they're looking at the right records for this Joe Smith.
0
Likes
1,083 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
