What Are Screens Good For?
Designing with Screens
After much research, sleepless nights, and debate, we finally settled on screens as the word we'd use to refer to the chunky, somewhat independent pieces of user interface (UI) in Indigo Studio. To give you some idea, some of the other players were: pages, windows, dialogs, popups, UIs, and views. Over the years, there have been many names to refer to basically the same thing in software—you know, the thing that people look at and interact with.
So it is inevitable that no matter what we picked, some people would find it wonky, some would think it is too vague, and some would think it too specific and constraining. Beyond the name, it is actually somewhat hard to define, as in write a definition for, a screen. For instance, how is a screen different from a control (aka element, widget, and so on)? In some technologies, the terms can be interchangeable even.
Further, how do you decide that some piece of UI that you want to design qualifies as a screen versus something else? I hope you see the issue. We settled on screen because, first of all, it seems more user-oriented. What does a user look at when dealing with software? Usually, a screen. Secondly, we feel that screen is generic enough to cover the various devices that most people design for today, and in terms of scope, we do mean (something that normally takes up all or most of the display device). For Web people, you can just imagine page where we say screen. For desktop OS type folks, you can probably think window for screen. Mobile folks, well, screen is just about right.
So a screen is just that big, chunky bit of UI that usually takes up most of your screen, whether that's a monitor or device screen. It's the main deal.
I doubt I need to tell you, generically speaking, what screens are good for, so let me tell you what they're good for specifically in Indigo. You can use them a few ways (and probably more than are mentioned here):
- To hold a sketch /mockup (image)
- To make a wireframe
- To design a page/window/dialog
- Do design a single-page app/prototype
- To explore a simple animation concept
- To quickly explore a single interaction flow
As you can see, screens are kind of the bread and butter of designing with Indigo, much like they are the bread and butter of modern software apps.
More on each of the listed ways to use Indigo below.
If you start out by sketching on paper or whiteboard, you can capture that as an image and drop it into a screen. Similarly, if you have an image-based mockup from another graphic design tool, you can drop that in. You can use copy/paste to add an image to a screen based on a screen capture.
You can use this approach to create clickable mockups—just plop a hotspot on and navigate to your next screen, and so on.
If you start like this, you can then eventually design the screen tracing on top of your sketch/mockup with Indigo screen elements to make a prototype.
Indigo has special support for importing Balsamiq® Mockups—you just copy from Balsamiq and paste into Indigo, and we'll do our best to recreate the Mockup using the corresponding Indigo screen elements, which you can then use to add interactivity to.
If you want to, you can think of a screen as roughly equivalent to a wireframe. Even if you don't want to create an interactive prototype, you can still use the Indigo screen elements to quickly design static wireframes.
If you want to structure your project like a Web site or a multi-window/screen application,you can use Screens to design the individual pages/windows/dialogs—like a Homepage, a Products List, and a Product page, for instance.
For Web sites, it is increasingly common to have an app that is actually just one "page" but dynamically changes its content based on user actions. You can do this in Indigo using one screen and designing its States (covered below).
Maybe you don't want or need to build a more holistic prototype; maybe you just want to try out a single animated transition. You can create a screen, add your elements, and then quickly try out animated changes to illustrate the transition you have in mind.
As with the previous way, maybe your needs are not to prototype a whole app but just one flow, maybe this is to fill in the blanks for a storyboard you designed. You can use a Screen to quickly bang out your idea following that one path, changing the screen in response to user actions.
We mention above that Screens have States in Indigo. So we should tell you about States, right? A state, simply put, is like a moment in the life of a screen. It is a kind of static configuration of all its UI elements. In that sense, it is much like a wireframe, and indeed, people often use wireframes to illustrate multiple states of a screen. The difference, in Indigo, is that all of those states are contained in a Screen. (Actually, there are other tools that also keep multiple states in one screen/file, but don't bring too much baggage from other apps because, depending on your app, Indigo may be more or less like it in relation to States.)
As you define interactions in Indigo, you can choose to create new States of a screen as the result of the interaction. In Indigo, interactions are made up of essentially two or three things:
- A user action – this is some action by the user (like tapping or hovering a mouse pointer) that you can use to cause some change in your prototype.
- [Optionally] Some changes to a screen – if you choose to create a new state, you simply start from the previous state and make changes to it, much like a user would experience in that case—there is no copying or pasting needed!
- Some resultant state—this can be a number of things, like a a new/different Screen, a URL opened, or, if you chose to, a new state (or a switch to an existing state).
So one way to use Screens—a very flexible and useful way—is to use multiple States in a Screen to represent your UI and how it changes in response to user actions. And by the way, this is usually the easiest way to create animated transitions as well!
Here are some suggested topics: