1 2 Previous Next

Qlik Design Blog

20 Posts authored by: Michael Anthony

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.

Data Literacy

Posted by Michael Anthony Mar 6, 2015

A skill set rarely discussed in the BI narrative is that of data literacy. Much is made of newer & more advanced visualizations, but the ability to understand what you are seeing and make smart decisions from that is incredibly valuable. Only a person with a great degree of data literacy can successfully both read & manipulate complex data to arrive at meaningful insights.

 

Reading & Writing

Data literacy comes in two parts: the front-end and the back-end. On the front-end a dashboard page requires the lowest degree of data literacy. Most people can read a well designed dashboard page and understand the general status of things. It is when the user advances to pages intended for critical analysis that the bar rises and users begin to drop out. Real analysis requires a data literate audience to get to the root cause of a KPI's status.

 

Marching hand-in-hand with front-end literacy is back-end literacy. While a great dashboard may not require much data literacy from the users it required a greater degree of data literacy from the person(s) who built it. What is the data being measured? Where does it come from? Are there compatibility issues between the data sets in an application? Building new visualizations or manipulating existing ones require familiarity with the data as well as how complex that data source is. Working with a simple data set requires relatively little data literacy but the more complex the data the greater the need for a data literate developer. Creating new objects is more than just technical development knowledge - it is understanding what you are measuring and why you want to measure it. Data literacy is often overlooked when it comes to the skill set of a great developer.

 

Increasing the data literacy of your organization, and yourself, is the key to spreading BI to the masses.

What is design? Who is a designer? I've been a designer for 13 years and what I do now isn't the same as what I started doing but I'm still a designer. I spent the first couple of years designing books and doing traditional ad agency work, eventually moving into User Experience design. While the nature of the output changed I was still a "designer" just in different mediums.

 

I've heard the term "designer" used to describe a wide variety of jobs. Usually when people outside of the creative world talk about designers they are thinking just about people who make things look nice. At the same time however I've heard Information Architects referred to as designers and they don't usually contribute to the aesthetic at all. So who's a designer? What defines a designer? I think the answer is in how you answer the larger question of, "what is design?"

 

What is Design?

Design is not defined by making things look pretty. Making things aesthetically pleasing can be a component of design, but it is not the sole defining factor. At it's most broad, design is problem solving. It is making a solution to meet the needs of other people (users). By this definition you can have well designed code, a well designed wire-frame, a well designed city, a well designed phone, a well designed experience, etc. It isn't necessarily about the visual. When something is well designed it meets the needs of the intended audience - it has solved a problem. User Experience design works to solve the problems of users interacting with an experience (usually digital). A UX designer then is someone taking human computer interaction knowledge, usability data, and visual design and bringing them together to create great interactive experiences that help people.

 

Still though the idea that great design means something looks great persists. Is Craigslist well designed? It isn't attractive but it has the content people want and it solves a problem. Is the Juicy Salif well designed? It's beautiful but the gold plated version can't be used to juice lemons because the acid in the lemons will destroy the gold. It can be challenging to define what makes great design, but at its core is the creation of something that solves problems for others.

With the gift-giving holidays comes all manner of gifts that require work before you can start doing the thing you wanted to do in the first place. Assembly, registration, installation - at best it is a momentary detour. At worst it is an infuriating concatenation of failure that leaves you not want the thing you are trying to use.

 

I spent part of Christmas helping relatives navigate the UX pitfalls/failures of setting up new pedometers, using web apps to upload photos to be printed, and getting photos onto a digital picture frame. With each test of patience I came away with one piece of solid UX advice: When in doubt, dumb it down.

 

When in doubt, dumb it down

Generic error messages, vaguely labeled options whose wording doesn't exactly apply to what a user is trying to do, hiding navigation, losing focus with extraneous options, clickable links that are disguised as plain text, inconsistent experiences across different device types - all of these help to reenforce the point that your users aren't mind readers; they don't have the knowledge that you had when you created an experience. The thing that is so obvious to you might not be obvious to them.

 

This is a message I've written about before but it bears repeating: you are designing for users of different ages, backgrounds, varying levels of technically savviness, different amounts of familiarity to the content. etc. You never know exactly who might be using your creation. User experiences should be obvious and easy to follow, lowering the barrier to entry for all potential users. If you are deciding between making something "cool" or painfully obvious, choose the obvious. Make your links look like links, make your labels specific to the content, make navigation items easy to find, etc. Steve Krug has written about this in his book Don't Make Me Think. If you are looking for a beginner crash-course to designing with usability & UX in mind his book is a good start.

vh.jpeg.jpg

When something is well designed it shows that time and consideration have been made to create something that is well thought-out and not just hastily thrown together last minute. It shows planning. It’s like wearing a well designed suit: it shows you put effort into presenting the best possible version of yourself.

 

In the 1970s & ‘80s Van Halen was one of the biggest rock bands in the world. They had a huge stage show: 9 eighteen-wheeler trucks full of equipment traveled with them from city to city and at every show this equipment had to be assembled and disassembled. Van Halen also had a rider – a rider is a list of the requirements & demands a performer or band need fulfilled in order to perform. It is the concert promoter’s job to meet all of these requests.

 

Usually you hear about a band’s rider when they make crazy requests such as how much alcohol they want, how many towels they need, exotic foods, etc. Van Halen’s rider was a massive document with mostly technical requirements on how to assemble their equipment but in the middle of the document, out of nowhere, there was a line-item that said there should be a bowl of M&Ms  but “…there will be no brown M&M's in the backstage area, upon pain of forfeiture of the show, with full compensation.” The no brown M&Ms became the stuff of rock lore but there was a really practical reason why it was included. The M&Ms were the canary in the coal mine, they were a visual indicator whether or not the rider had been read in detail and followed. The band knew that if the concert promoter didn’t catch that detail then guaranteed if they did a line inspection of the equipment there would be other problems.

 

To Van Halen the brown M&Ms were a reflection of the concert promoter’s attention to detail. They knew if this simple front-end item was broken then guaranteed there were more problems on the back-end, that the concert promoter didn’t take the time to pay attention to all of the necessary details.

 

Like seeing brown M&Ms, a poorly designed application can be treated with suspicion as to the overall quality. We generally consider well designed items to be of better quality. Good design is an indicator that something is smart and well created - that the designer knows what they are doing. Take the time to consider the design of your applications because your users certainly will.

Raw data is useful but data with additional contextual information is better because it helps us do what we already do naturally: compare, contrast, and weigh our options as part of the bigger picture. Contextual data is the supporting information that helps the reader more fully understand the primary data.

 

Key performance indicators (KPIs) at the top of a Dashboard page are a great way to give the general summary of how something is functioning, but the very next thought in any reader's mind is about context. Only people who are very familiar with the data can look at a number and place it in the context of the full story.  The rest of us need additional information to contextualize this data. There are a variety of simple ways to give readers additional context so they can make smarter decisions.

 

Traffic light

One way most people in BI are familiar with providing additional context is color coding information with traffic light colors. Green is good, yellow is a warning, red is bad. This visual metaphor is so common that most people understand it without any additional information. You might not know why a number is red, but at least you know there is a problem. Something to consider however is using an additional visual cue along with this metaphor for color blind users. Red-green color blindness is the most common form of color blindness which is where red & green colors shift to being shades of yellow and brown. You can use shapes / symbols along with your colors to improve the accessibility of this system. Perhaps you use up or down triangles in addition to coloring them green or red. Perhaps a fully colored circle can be green for good where an empty circle with just a red border can be bad. The shape is an additional indicator to users who have difficulty seeing the differences in your colors as to the context of your data.

 

cfo dashboard.png

color-blindness-simulation.jpg

Lines & Bars

Having a simple line or bar chart below a KPI can quickly place a KPI in the context of a larger whole. These are charts with no axes or written values. They are simply there to give context - drilling into the details is done elsewhere.

  • A line chart helps show the overall trend. To see a KPI number in green is useful, but more useful is to see that perhaps the overall trend in sales is going down and pretty soon that number might be red.
  • A bar/bullet chart is useful for showing, among other things, the completion of goals. Show a goal/reference line and show how well you met or exceeded that goal. This is essentially a more streamlined, quieter, more aesthetically pleasing version of a gauge chart.

 

procurement.png

 

This time last …

An additional piece of context you can add is some variation of "This Time Last …" year, quarter, month etc. You communicate to the reader that at some previous point in time the value of this field was something else and you are helping them compare the two values and judge if progress is being made.

 

this time last.png

 

You can employ any/all of these in your designs to help bring context to the data and enable users to make smarter decisions.

Not all of your data is equally important. Some things are more important than others. It’s your job as the creator of a guided analytics application to prioritize information, to create a hierarchy for users to better understand the information. There is an implied level of importance based on where you place something and what it looks like.

 

Be on the front page

Being on the first page someone sees when starting an experience is best. Like the front page of a newspaper the Dashboard of an application has an added level of importance by the very nature of being first. What you choose to lead with says a lot about what you want your audience to know above all else. It isn't that the subsequent pages aren't important it is just that they are perceived as less important in the hierarchy of pages because they aren't first. Leading with a Dashboard page is all a part of the DAR methodology which is a useful way to organize your content across multiple pages.

 

Top of the page

Like being the first page a user sees, being at the top of the page is prime real-estate. Designers use placement to denote importance online all the time. In ecommerce design the top area (the Aspot) is the largest marketing space and has the greatest prominence. From there subsequent spaces (B spots, C spots, etc.) cascade down the page in lesser and lesser importance. The further down the page something is, the less important it is. Content at the top of the page sits above the fold (to reference newspapers again) and therefor should be universally seen by users on any device resolution before scrolling.

 

F formation down the page

While we may read long-form content in a Z formation down a page we scan/read most online content in an F formation. We read the first line, then a bit of the second line, then sort of work our way down the left side of a page hunting for keywords. This works for article pages online but it also works with larger object oriented pages like shopping experiences with product photos. Again this reaffirms that the content at the top of the page is the most important real-estate on a page especially the top left. The top of the page gives a reader an idea of what content a page may contain and the scent of whether or not he/she is on the right track to finding what they are looking for.

 

Style

Other than being at the top of the first page a final technique to denote importance is how you choose to size & style your content. Most people are familiar with this concept as it applies to typography. Magazines, newspapers, websites, etc. all make the most important information the largest type size. As the type sizes are reduced the implied importance of that information is also diminished. You can also use contrast to set some information apart from the rest. Where all of your text is a dark gray perhaps one part is bright red. Where most of your lines in a line chart follow a similar color scheme, perhaps one contrasts that scheme to stand out. Essentially you are telling the user that this thing that visually stands apart from the rest is important and something they should focus on.

 

Establishing a hierarchy of information is beneficial to the user of a guided analytics application because it reduces the cognitive load of the user. When users don't have to sift through all of the content to decided what is most important they have more time to focus on using the application and meeting their business needs.

The Demos & Best Practices team are often asked to look at applications built by third parties and give feedback. This feedback covers technical QlikView recommendations as well as design & usability best practices. Being on the outside looking in our team tends to approach these apps in ways their developers usually haven't considered. Very often these apps are being built by developers who have been so focused on making sure the data is correct they haven't stopped to consider the user experience until they are almost finished.

 

With that in mind the following are a four pieces of design advice that we tend to give fairly often.

 

 

Boxes boxes everywhere.

Many developers leave borders, shadows, and caption backgrounds on their charts and list boxes. These are some of the first things the Demos & Best Practices team remove when we are overhauling an app. When every object is fenced in it makes the entire app look very boxy where all of the objects are their own little entities isolated from the other charts. Even if you aren't convinced by this reasoning the question we would pose is "how are these borders, shadows, etc. helping the app?"

 

No 3D charts … ever.

Like something out of Mommie Dearest you shouldn't use 3D charts. Ever. Aside from the fact that they are "aesthetically unappealing" they make reading the data difficult. In a 3D vertical bar chart does the bar terminate at the front/bottom of the top plane, the middle of the top plane, or the back/top of the plane? How are shadows in a line chart helping you to analyze your business? Is a 3D pie chart tilted into perspective easier to understand than a standard pie chart? There are ways to be creative and add some visual fun into your design (backgrounds, slight shadows dividing up the space of an app, a few icons, etc) but 3D charts isn't one of them.

 

Include a Dashboard page

Under the pressure to develop an app that works many developers focus on creating a variety of ways to analyze the data but forget to have a page that summarizes the data. Include a Dashboard page that gives the summary of the app. If the app is about sales include the major sales figures as well as reference sales goals and whether or not those goals were met. Who were the top five sales people? Who were the lowest five? Give a list of your top selling items as well as your worst selling ones. If it is a medical application give some high level numbers about the number of patients, doctors, hospital staff and if they are up or down from this time last year/quarter/month etc. What is the average wait time to see a doctor? How many procedures have been ordered lately and what are they costing? There are unlimited possibilities of what you could include but the idea is to give your users an overall summary of the status of things before they go into a deep dive and analyze the numbers.

 

Be Consistent

If you have reoccurring objects that are on many pages keep them in the same location on each page. Use the same colors and font sizes for like minded labels, captions, and text. Design all of your pages to the same width. When things jump around it creates dissonance and users have to adjust and learn how to navigate each page. This process takes time & cognitive effort and is detracting from the time & effort they should be dedicating to using your application. Pick a style and stick to it.

History is scattered with luminaries who used personal reflection to change their lives. From the personal journal entries of James Boswell to the more scientific daily measurements of Sanctorius Sanctorius, people have used qualitative and quantitative records to better understand themselves. The inventor of seemingly everything, Benjamin Franklin, had a system to measure how well he lived his 13 virtues on a daily basis using the data to see where he went wrong with the intention of ultimately living a life free from transgression.

 

Over the last several years personal activity trackers have gained significant traction in the market place. BI Intelligence has conservatively forecasted a $12 billion market for wearable devices over the next 5 years. I've been using a Fitbit device for the past few years but I have also been tracking a variety of data points more manually for the last 5 years. Actively collecting & analyzing personal data definitely places me in the minority but also potentially as an early adopter.

 

As technology gets smaller and less expensive more and more people are actively & passively tracking data about themselves. Just looking at the news shows us how much data we are passively (sometimes unknowingly) generating about ourselves and is being used by big business and big government.

 

 

When will this wave of passive data collection break into active mainstream collection & use of data?

In some ways many people already do actively collect data. People are regularly posting thoughts to Twitter and Facebook which can be used as a running tally of feelings and analyzed for sentiment. Runners and cyclists have been using various hardware and smartphone apps for years now to analyze their performance. People can count calories and check their weight. We have credit card statements of how much we spend as well as investment data on how our money is performing. The problem though is that, with a few exceptions, most of this data is never seriously analyzed by the people generating it. Further, most of the data is left as isolated data sets and is rarely brought together into one consolidated view. Several activity trackers have ways of feeding other activity oriented data into their Dashboard pages but even then they remain isolated from other personal data.

 

So what's the hold up? Why is the notion of the quantified self still seen as a fringe concept? There are a few answers but two specifically. First, most people aren't very technical and connecting all these disparate data repositories is still not easy. A second answer could lie with the concept of path dependence. Most people don't actively collect & analyze personal data and it's easier to just keep not collecting & analyzing personal data. You have to go out of your way to get started and since most people you know aren't doing it it's hard to see the value.

 

So why develop your quantified self?

The answer is varied and up to you. Looking around the internet you can find a variety of people who collect personal data and study their own behavior for a variety of reasons. Nicholas Felton generates a very well designed personal annual report each year of his activity; Thomas Christiansen has studied how many times, and the circumstances under which, he sneezes to better understand his allergies. Most people collecting & analyzing their own data are doing so to improve some aspect(s) of their own lives.

 

One of the nice things about using data is that it is an impartial and detailed mirror of our lives. The human brain is greatly influenced by a variety of cognitive biases. In short we forget things and we aren't great at thinking about ourselves in the future. We suffer from impact bias which is the tendency for our prefrontal cortex to not simulate future situations as well as we think it can. To help make new or better decisions it is nice to have an impartial record of our behavior that might steer us towards the best (and possibly different) future course of action other than the one our brains may have imagined on their own.

 

As Richard Buckminster-Fuller said "There is no such thing as a failed experiment, only experiments with unexpected outcomes."

(un)originality

Posted by Michael Anthony Dec 27, 2013

Who you are is the product of all of the experiences you have had, and not had, throughout your lifetime. Nobody operates in complete isolation. Everyone is influenced by sources outside of themselves. We take those experiences and internalize them with our other memories in our own way but ultimately everything you come in contact with serves as material for the future you. So it stands to reason that new ideas & creativity are also the result of taking existing ideas and transforming them.

 

People frequently talk about ideas/people as being "totally original," but the truth is that originality is rather unoriginal. People with seemingly totally new ideas are really just the result of taking existing concepts and bringing them together in new ways. Perhaps you can identify the original source material, perhaps you can not, but everyone is influenced by ideas outside of themselves and nobody creates something entirely new.

 

The 4 part video series Everything is a Remix is a fantastic exploration of this in action. From music, to film, to mechanical invention everyone is influenced by the work of others.

DAR methodology

Posted by Michael Anthony Nov 8, 2013

Nobody likes to constantly reinvent the wheel. Completely starting from scratch on something you work on all of the time is a waste of time. People reuse parts of old QVWs all the time to save the time & effort of redoing the same things over and over again.

 

The Dashboard, Analysis, Reporting (DAR) methodology is a foundation you can build all of your applications on while still having room to be creative and meet the varying requirements of individual clients / prospects.

 

In a nutshell you lead with a Dashboard page, followed by Analysis pages, and finish with Reporting pages.  The Dashboard gives the high level overview of the business, the Analysis pages give interactive user-driven controls to filter the data, while the Reporting pages give the most granular details. The system works on a few levels but to understand some of why it works we have to discuss how people interact with computers and how we perceive information. The attached technical paper gives an introduction into Human Computer Interaction (HCI), about Top Down versus Bottom Up perception, and how all of this comes into play in QlikView.

Modern data visualization and business intelligence has its roots in the very ancient organization methods of information itself. One of the earliest forms of organization was simply drawing lines in the dirt or sand. This gave way to using beans or stones moved around in grooves in the dirt/sand and eventually on stone or wooden boards. This became what we now know as the abacus between 2700–2300 BC with the Sumerians. The abacus was then adopted by cultures all around the Mediterranean. As written languages developed and matured there became written records of information regarding a variety of fields such as commerce, taxation, the sciences, etc. This information remained as written text however. There was no easy way to see trends or outliers in the data collected.

 

Data visualization really took off in the 18th century when William Playfair, a Scottish engineer & political economist, brought the intellectual enthusiasm of the Enlightenment to data. Playfair went on to invent the line, bar, pie, and circle charts. Other notable visualizations followed such as Dr. John Snow's 1854 dot distribution map of cholera cases in London, Florence Nightingale's polar area diagram visualizing mortality rates in the field hospitals she managed during the Crimean war, and Charles Minard's 1869 flow map of Napoleon's failed Russian campaign of 1812.

 

Fast forward to the 1950s when IBM researcher Hans Peter Luhn coined the term "business intelligence" in his 1958 paper A Business Intelligence System. His work laid the groundwork for modern information sciences. What we largely recognize as modern BI really developed over the years beginning in the 1960s right up through the 1980s. Statistician Francis Anscombe helped demonstrate the value of data visualization in his 1973 Anscombe's quartet which is a series of four datasets with nearly identical properties but look very different when visualized. He was making the point that relying solely on a table of values wasn't enough to fully understand the data. Visualizing the data was crucial to seeing trends and outliers.

 

Our modern tools for Business Intelligence have never been more powerful. The challenge of taking action on your data though is largely the same today as it was thousands of years ago. Businesses and individuals are increasingly looking for ways to not only see their data but understand it in ways unimaginable to our ancestors drawing lines in the sand.

Mobile access to information is becoming big business. While the share of the mobile market depends on what study you read, a 2012 study by Chitika said US mobile devices accounted for about 20% of all US internet traffic. Of that 20% smartphones were 14.6% while tablets were 5.6%. These numbers are all up from previous years. As the number of devices increases so too does the power of these devices. Mobile devices are moving away from being solely information consumption devices and into the realm of information creation devices. As the hardware becomes more powerful, and the user experiences become more sophisticated, our mobile devices are allowing us access to interact with information from anywhere. With this groundswell in mobile are increased expectations from users for well-designed, considerate, intelligent designs that work well on the device at hand. Smartphone experiences shouldn’t be the same as desktop experiences but it should be just as good. The usability considerations for how we interact with these devices can be very different from device to device.

 

The attached technical paper begins to address some mobile usability considerations. The summary of this paper is that:

•       The conversation around mobile devices is less about Consumption vs. Creation and more about Task Complexity vs. Task Duration.

•       Properly sized designs for the desktop experience will also work for the tablet experience.

•       Smartphones want customized experiences.

•       Progressive disclosure is more important than ever on smartphones.

•       How people interact with touch-based devices influences success rate of applications.

•       Leave room to enable scrolling.

Usability engineers & researchers are crucial parts of User Experience. While not as "glamorous" as designers they bring evidence to the world of design. Through observation of heuristic tests they offer empirical evidence that a design is working, failing, what users like, what users aren't finding, what users are doing that they don't even realize they are doing it, etc. Usability is the closest thing design has to being a science.

 

The attached technical paper goes through a variety of topics with usability in mind and makes recommendations. It links out to studies and research already done supporting best practices.

 

The basic findings and recommendations in this document are that:

• People don’t read everything online, they skim

• Paragraph width impacts comprehension

• Scrolling is good

• Monitor Resolution: design for 1024x768

• Ipads: design for 1024x768 and allow scrolling

• Icons don’t necessarily help usability

• Filters should be on the left

Knowing when to show more information and when to show less is not only good design it's good usability. The more information you present the greater the cognitive load a user has to juggle to accomplish a task. Sometimes you want to have lots of information visible to make the best choice but other times you don't. There is a point of diminishing returns where you have given your users too much information too soon. Sometimes people need to ease into an application, get acquainted with it, and then proceed to learn more.

 

Progressive disclosure is when information is sequenced out across several pages or screens to help a user process information and to avoid overwhelming them with too much information. Additional information, or more advanced or rarely used features, are hidden away until needed. This is a technique that was used by IBM in the 1980's when developing user interfaces. They realized that progressively disclosing additional tasks and information through a series of menus was better than having everything present up front. It managed complexity by clearing up clutter. It helped new users get familiar with the UI and as they became more savvy users they used the menu systems to find more advanced functionality.

 

The attached Technical Paper discusses a bit more how progressive disclosure is useful in BI. Progressive disclosure helps the DAR methodology to give users the general summary on the Dashboard, more advanced functionality on the following pages, and then the real deep dive information for Reporting. Progressive disclosure helps you design for other people at a variety of skill levels to get the most out of your applications.

Filter Blog

By date:
By tag: