Copy paste work from home without investment in pune

This draft was released March 15, Please email comments to bret worrydream. You can also download the PDF. Information software design can be seen as the design of context-sensitive information graphics.

I demonstrate the crucial role of information graphic design, and present three approaches to context-sensitivity, of which interactivity is the last resort. After discussing the cultural changes necessary for these design ideas to take root, I address their implementation. I outline a tool which may allow designers to create data-dependent graphics with no engineering assistance, and also outline a platform which may allow an unprecedented level of implicit context-sharing between independent programs.

I conclude by asserting that the principles of information software design will become critical as technology improves. These are contentious definitions; hopefully, this paper itself will prove far more contentious. It cannot be seen or touched. It is not composed of matter at all.

However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. Merlin had it easy—raising Stonehenge was a mere engineering challenge. He slung some weighty stones, to be sure, but their placement had only to please a subterranean audience whose interest in the matter was rapidly decomposing. The dead are notoriously unpicky. Instead, their vivified creations often resemble those of Frankenstein—helpless, unhelpful, maddeningly stupid, and prone to accidental destruction.

For decades, the usability pundits have devoted vim and vitriol to a crusade against frustrating interfaces. Yet, software has remained frustrating, and as the importance of software to society has grown, so too has the crisis. The crusade marches on, with believers rarely questioning the sacred premise—that software must be interactive in the first place.

Perhaps the spark of life is misdirected magic. These are not brave new realms of human endeavor. We share the blood of cavemen who pushed spears into mammoths and drew pictures of them in the living room.

By now, these two activities have evolved into well-established design disciplines: Graphic design is the art of conveying a message on a two-dimensional surface.

This is a broad field, because people have such a variety of messages to convey—identity, social status, emotion, persuasion, and so on. Most relevant to software is a branch that Edward Tufte calls information design —the use of pictures to express knowledge of interest to the reader. Some products of conventional information graphic design include bus schedules, telephone books, newspapers, maps, and shopping catalogs.

A good graphic designer understands how to arrange information on the page so the reader can ask and answer questions, make comparisons, and draw conclusions. When the software designer defines the visual representation of her program, when she describes the pictures that the user will interpret, she is doing graphic design, whether she realizes this or not.

Industrial design is the art of arranging and shaping a physical product so it can be manipulated by a person. This too is a broad field, because people work with such a variety of objects—cutlery to chairs, cell phones to cars. A good industrial designer understands the capabilities and limitations of the human body in manipulating physical objects, and of the human mind in comprehending mechanical models. A camera designer, for example, shapes her product to fit the human hand.

Just as importantly, she designs an understandable mapping from physical features to functions—pressing a button snaps a picture, pulling a lever advances the film, opening a door reveals the film, opening another door reveals the battery. Although software is the archetypical non-physical product, modern software interfaces have evolved overtly mechanical metaphors. Buttons are pushed, sliders are slid, windows are dragged, icons are dropped, panels extend and retract. People are encouraged to consider software a machine—when a button is pressed, invisible gears grind and whir, and some internal or external state is changed.

Manipulation of machines is the domain of industrial design. When the software designer defines the interactive aspects of her program, when she places these pseudo-mechanical affordances and describes their behavior, she is doing a virtual form of industrial design. Whether she realizes it or not. The software designer can thus approach her art as a fusion of graphic design and industrial design. Software is for people. To derive what software should do, we have to start with what people do.

Consider the following taxonomy of human activity: Consider it a set of basis vectors into the space of human activity. Different basis sets are helpful for reasoning about different problems, but they all describe the same space.

But people are increasingly shifting their intellectual activities to the virtual world of the computer. This suggests three general reasons why a person will turn to software:. I propose that software can be classified according to which of these needs it serves. I will call these categories information software, manipulation software, and communication software. Information software serves the human urge to learn.

A person uses information software to construct and manipulate a model that is internal to the mind —a mental representation of information. Good information software encourages the user to ask and answer questions, make comparisons, and draw conclusions.

A person would use recipe software, for example, to decide what to cook for dinner. In effect, she is constructing an internal understanding of culinary possibilities, and mentally prodding this model to reveal the optimal choice. Manipulation software serves the human urge to create. A person uses manipulation software to construct and manipulate a model external to herself —a virtual object represented within the computer, or a remote physical object. Some examples include software for drawing, writing, music composition, architectural design, engineering design, and robot control.

Manipulation software can be considered a virtual tool —like a paintbrush or typewriter or bandsaw, it is used as an interface between creator and artifact. Communication software serves the human urge to communicate. A person uses communication software to construct and manipulate an internal model that is shared with others —an understanding synchronized across multiple minds.

Examples include software for email, group discussions whether voice, video, or textand collaborative working. In terms of raw mechanics, communication can be thought of as creating a response to information learned —that is, the external model manipulated by the speaker is the internal model learned by the listener. Thus, this paper will simply treat communication software as manipulation software and information software glued together, and mention it no further. This design approach is widespread—email software typically has separate reading and writing modes; messageboards similarly segregate browsing and posting.

Manipulation software generally displays a representation of an object—the model—which the user directly manipulates with pseudo-mechanical affordances. Because manipulation is the domain of industrial design, manipulation software emphasizes industrial design aspects. Consider a tool for laying out a small newspaper. The user will spend most of her time performing a number of pseudo-physical operations—writing, drawing, cutting, moving, rotating, stretching, cropping, layering—within a virtual space.

The primary design challenge, just as with any industrial design, is to provide affordances that make these mechanical operations availableunderstandableand comfortable. However, in a physical space, each operation would use a specialized tool. Although manipulation is the focus, good manipulation software must provide superb visualization as well. This establishes the feedback loop that is critical for all creative activity—the manipulator must see the effects of her manipulation.

Thus, manipulation software design is also a significant graphic design challenge. For example, the newspaper editor needs to see what a page looks like—close-up, from a distance, and in relation to other pages—and how it would look in a variety of other configurations.

She wants to see misspelled words, lines that are poorly justified or hyphenated, and widows and orphans. She wants to see columns that are short or overlong, and how they can be corrected by changing column width or leading. She wants to know what stories and ads are still on the table, their sizes, and how they can be fit in.

She wants to know how recently and how often stories about a given topic have run, and how readers have responded. She wants to know past response to a given ad, as a function of the topics or authors of the stories it was coupled with. Finally, the presentation of all this information must not distract the editor from the primary task of manipulating the layout. Furthermore, the industrial and graphic designs in manipulation software must be in intimate synergy, since it is the graphic design which describes how the object can be manipulated—the mechanical affordances are graphical constructs.

Even more graphically challenging is manipulation of abstract objects, such as music or financial data, where the graphical representation must show not only what can be done with it, but what it is in the first place.

Fortunately, for an enormous class of software, manipulation is not only largely unnecessary, but best avoided. Much more time went into finding or obtaining information than into digesting it. Hours went into the plotting of graphs, and other hours into instructing an assistant how to plot.

Their primary concern was how a machine could help a person find and understand relevant knowledge. Although they were generally discussing scientific and professional work, their prescience fully applies in the modern home.

Most of the time, a person sits down at her personal computer not to create, but to read, observe, study, explore, make cognitive connections, and ultimately come to an understanding.

This person is not seeking to make her mark upon the world, but to rearrange her own neurons. The computer becomes a medium for asking questions, making comparisons, and drawing conclusions—that is, for learning. People turn to software to learn the meaning of words, learn which countries were bombed today, and learn to cook a paella.

They decide which music to play, which photos to print, and what to do tonight, tomorrow, and Tuesday at 2: They keep track of a dozen simultaneous conversations in private correspondence, and maybe hundreds in public arenas.

They browse for a book for Mom, a coat for Dad, and a car for Junior. They look for an apartment to live in, and a bed for that apartment, and perhaps a companion for the bed. They ask when the movie is playing, and how to drive to the theater, and where to eat before the movie, and where to get cash before they eat. They ask for numbers, from simple sums to financial projections.

They ask about money, from stock quote histories to bank account balances. They no longer sit on the porch speculating about the weather— they ask software.

Much current software fulfilling these needs presents mechanical metaphors and objects to manipulate, but this is deceiving. People using this software do not care about these artificial objects; they care about seeing information and understanding choices—manipulating a model in their heads. For example, consider calendar or datebook software. To me, it is about combining, correlating, and visualizing a vast collection of information.

I want to see my pattern of working late before milestones, and how that extrapolates to future milestones. I want to see how all of this information interrelates, make connections, and ultimately make a decision about what to do when.

My goal in using calendar software to ask and answer questions about what to do when, compare my options, and come to a decision. Consider personal finance software.

Entering and classifying my expenses is, again, tedious and unnecessary manipulation—my credit card already tracks these details. I use the software to understand my financial situation and my spending habits. How much of my paycheck goes to rent? How much to Burrito Shack? If I give up extra guacamole on my daily burrito, will I be able to buy a new laptop?

If I buy a hybrid car, how much will I save on gas? I want to ask and answer questions, compare my options, and let it guide my spending decisions. Consider an online retailer, such as Amazon or Netflix. The entire purpose of the website—the pictures, ratings, reviews, and suggestions—is to let me find, understand, and compare their offerings. The experience is about building a decision inside my head. In the end, I manipulate a shopping cart, but that is merely to put my mental process to effect, to reify the decision.

At the best retailers, this manipulation is made as brief as possible. Even consider reading email. Most current designs revolve around the manipulation of individual messages—reading them one-by-one, searching them, sorting them, filing them, deleting them. But the purpose of reading email has nothing to do with the messages themselves. I read email to keep a complex set of mental understandings up-to-date—the statuses of personal conversations, of projects at work, of invitations and appointments and business transactions and packages in the mail.

That this information happens to be parceled out in timestamped chunks of text is an implementation detail of the communication process. It is not necessarily a good way to present the information to a learner.

Similar arguments can be made for most software. So far, this categorization has just been an exercise in philosophy. But this philosophy suggests a very practical approach to software design. My demands are perfect examples of graphic design challenges.

A well-designed information graphic can almost compel the viewer to ask and answer questions, make comparisons, and draw conclusions. It does so by exploiting the capabilities of the human eye: Meanwhile, a graphic sidesteps human shortcomings: This design may be adequate for commuters, whose questions mostly concern when trains arrive at stations.

But train system operators have a different set of questions: Where exactly are the trains at any given time? How fast are they moving? Where do two trains cross? They better not be on the same track at that point! Where are the trains at the start of the day, and where do they end up at night? If a train is delayed, how do all these answers change? Like some of the software questions above, these questions seem very difficult to answer. But consider this revised timetable design:.

Each train is represented by a distinctly-colored line, with distance along the track plotted vertically and time horizontally. Important features such as crossings are emphasized simply because the eye is naturally drawn toward line intersections. Footnotes are unnecessary; the exceptions are no longer exceptional when seen in context.

Compared to excellent ink-and-paper designs, most current software communicates deplorably. This is a problem of surface, but not a superficial problem. The main cause, I believe, is that many software designers feel they are designing a machine. Their foremost concern is behavior—what the software does. They start by asking: What functions must the software perform? What commands must it accept? What parameters can be adjusted?

In the case of websites: What pages must there be? How are they linked together? What are the dynamic features? These designers start by specifying functionalitybut the essence of information software is the presentation. It must be mentioned that there is a radically alternative approach for information software— games. Playing is essentially learning through structured manipulation—exploration and practice instead of pedagogic presentation.

Despite the enormous potential for mainstream software, accidents of history and fashion have relegated games to the entertainment bin, and the stigma of immaturity is tough to overcome. The situation is similar for graphic novels. I suggest that the design of information software should be approached initially and primarily as a graphic design project.

The foremost concern should be appearance—what and how information is presented. The designer should ask: What is relevant information? What questions will the viewer ask? What situations will she want to compare? What decision is she trying to make? How can the data be presented most effectively?

The designer must start by considering what the software looks likebecause the user is using it to learn, and she learns by looking at it. Instead of dismissing ink-and-paper design as a relic of a previous century, the software designer should consider it a baseline.

It seems that many software designers, in their focus on functionality, forget to actually present the data. Consider the information presented when searching a popular online bookstore. There are a number of graphic design criticisms one could make—the uniform text size and weight results in a solid, oppressive mass; the abundance of saturated primary colors gives a distracting, carnival-like appearance; the text is spread all over the page, giving the eye no well-defined path to follow.

However, the most egregious problem is simply that there is not enough information to make any sort of decision.

Given that the books shown are presumably related to this topic, what questions does the user have? The answers will be used to compare the available books, and decide upon one to follow up on and possibly buy.

Unfortunately, these questions are completely unaddressed by the information provided. To see relevant information, the user must click on each listing individually. That is, she must navigate by hand instead of by eyeand must use her memory to compare information across time instead of space.

The problem is that this graphic was designed as an index into a set of webpages, but is used as a catalog for comparing a set of books. The purpose of this graphic should not be to return a list of query matches, but to help the user learn about books related to her topic of interest.

Is a book appropriate? Is a book good? A rating and reviews indicate popular opinion. Because all of this information is on a single page, it can be compared by eye, with no need for memory. The standard 5-star rating system is information-weak—it gives only an average.

It can be enhanced with whiskers underneath that indicate the distribution of ratings. This allows the viewer to differentiate between a book that was unanimously judged middling and one that was loved and hated —these are both 3-star ratings, but have very different meanings. The viewer can also see whether a highly-rated book got any bad reviews; in a sea of praise, criticism often makes enlightening reading.

As a whole, the whiskers give a visual indication of the number of ratings, which reflects the trustworthiness of the average. Text weight and color is used to emphasize important information and call it out when skimming. Text in grey can be read when focused upon, but disappears as background texture when skimming. All critical information is contained in a column with the width of an eyespanwith a picture to the left and supplementary information to the right.

The viewer can thus run her eye vertically down this column; when she spots something interesting, she will slow down and explore horizontally.

Online Works in India - Online Ads Posting Jobs Copy Paste Jobs Data Entry Jobs in India

The user wants to see books related to a topic in her head. But ideas in the head are nebulous things, and may not translate perfectly to a concrete search term. For this reason, a mini-list of related books is provided for each book.

Conventional software designers will worry about functionality—how does the user interact with this graphic? What else could the user mean by clicking? This is a significant redesign over the original; yet, I consider it a conservative one.

A more ambitious design could surely show even more data, perhaps allowing the user to browse within the book or fully explore the space of related books. A world of possibilities opens up with a simple change of mindset. This is not a list of search results—it is an information graphic. It is for learning. Just as important as what data is shown is where it is shown. Unlike the words in a paragraph, the elements in a graphic can be deliberately placed to encourage spatial reasoning.

Unfortunately, most software graphics are arranged to maximize aesthetics, not to bring out useful relationships in the data. That is, when any skilled thought is given to appearance at all. Consider this excerpt of a graphic for browsing nearby movie showings: The user will use the answers to compare the available movie showings and decide upon one to go see.

Although the above graphic clearly has an information deficiency What are these movies about? Understanding which movies are playing when involves scanning a pageful of theaters, extracting movies of interest and mentally merging their showtimes.

As with the bookstore redesign, enough information is given about each movie to determine its content and quality, although films have enough external marketing that the intent is more to remind than introduce. Text weight is again employed to make critical information stand out and supplementary information disappear until focused upon. More interesting is the chart on the right, which plots movie showings by time.

To find all movie showings around a particular time, the viewer simply scans her eye vertically down the page. The original design grouped movies by theater; this redesign groups theaters by movie.

Magic Ink: Information Software and the Graphical Interface

The assumption is that the viewer would rather see a particular movie at any theater than any movie at a particular theater. However, to ease correlation of the various movies offered at a given theater, each theater is color-coded. If the viewer prefers to avoid the Gulliver Theater because of sticky floors, the consistent yellow background may help her filter out its showtimes.

No theater addresses are shown. This demonstration and the previous one have attempted to illustrate the power of approaching information software as graphic designinstead of as styling the regurgitation of a database. To design excellent software, however, this mindset is necessary but insufficient. Something major is missing. Very little in the above designs is software-specific. For the most part, the designs would work almost as well on paper.

Print has one supreme flaw: An ink-and-paper design is static—it must display all its data, all the time. However, a reader typically only cares about a subset relevant to her current situation. The designer is faced with the challenge of organizing the data so that hopefully mutually-relevant subsets are grouped together, and the reader has the challenge of visually or physically navigating through the entire data space to find the group of interest.

For example, a rider consulting a bus schedule must comb through a matrix of times and stations to find the single relevant data point—the time of the next bus. And a reader consulting an encyclopedia must not only find the right entry on the page and the right page in the book, but even the right book on the shelf! These are consequences of static graphics. Because ink is permanent, the reader must navigate through lots of paper.

The modern computer system provides the first visual medium in history to overcome this restriction. Liberating us from the permanence of publication is the undersung crux of the computer—the dynamic display screen.

Its pixels are magic ink—capable of absorbing their context and reflecting a unique story for every reader. And the components surrounding the display—CPU, storage, network, input devices—are its peripherals for inferring context.

Information software design, then, is the design of context-sensitive information graphics. Unlike conventional graphics, which must be suitable for any reader in any situation, a context-sensitive graphic incorporates who the user is and what exactly the user wants to learn at the moment.

All information software consists of context-sensitive graphics, whether the designer realizes it or not. For example, the list of query results from an internet search engine is a context-sensitive information graphic.

This is winnowed down to a dozen, using context that is inferred entirely from the search term contributed by the user. Despite its enormous data space, this software restricts itself to a meager scrap of context, impersonal and imprecise.

A person determines her surroundings through the five human senses. A person using a software bus schedule, for example, should never have to hunt for the next bus. Developers would then write software to take advantage of it, and other computer makers would follow suit. Someday, a computer without GPS might seem as silly as a computer without a clock. Given a time and location, many details of the physical environment, such as the weather, are just a network connection away.

Consider a travel guide that suggests parks when sunny and museums when rainy. Other information softwaresuch as open websites. By reading some information, the user is indicating a topic of interest. All other information software should take heed.

Consider a person reading the website of an upcoming stage play. When she opens her calendar, the available showings should be marked. When she opens a map, she should see directions to the playhouse. Documents created with manipulation software. Creating some information indicates an even stronger topic of interest. Names, addresses, and phone numbers in recent email clearly constitute valuable hints.

When she opens a map, addresses in the email should be marked. All software lives within an environment, rich with evidence of context. Implementation will be discussed later in the paper. On the other hand, the power of the environment is multiplied when it is correlated with the past—that is, when the software makes use of history. Software, too, can use its memory to understand the present.

The current context, or a good approximation, can often be predicted from a history of past environments and interactions. Last-value predictors represent the simplest form of prediction. They simply predict the current context to be the same as the previous one. For example, if yesterday, the user looked for one-bedroom apartments in North Berkeley, she is is probably still interested in one-bedroom apartments in North Berkeley today.

If nothing else, the software should present this information immediately, without asking for details. Last-value prediction is frequently thought of and implemented as manipulation of explicit state—that is, the context is a persistent object that remains as is unless changed by the user, so the software always appears as the user left it.

Often, not even this is bothered with. However, this is often not the case with information software, especially software that is consulted intermittently. On the other hand, you would be delighted if you often came back to find it on exactly the page you wanted to read. By thinking of this as context prediction instead of state maintenance, the door is opened to more sophisticated predictors.

Learning predictors attempt a deeper understanding of the user. They construct a model to explain past contexts, and use the inferred relationships to predict the current context. For example, in a music library, as the user chooses several bluegrass songs in a row, the software can graphically emphasize other songs in this genre. With further confidence, it might consider de-emphasizing or omitting songs outside of the genre. In fact, information about Maya could be presented automatically.

If a person asks a travel guide about the Grand Canyon on one day, and Las Vegas the next day, the following day the software might suggest attractions around Los Angeles. As an example of general pattern modeling, consider a person who, as a byproduct of traveling to work, always checks the train schedule from Berkeley to San Francisco in the morning, and San Francisco to Berkeley in the evening.

If the software can discover and model this pattern, it can present the appropriate information at each time without the user having to request it. When she looks in the morning, she sees by default the San Francisco-bound schedule; in the evening, the Berkeley-bound schedule. New York TimesJan. TiVo similarly uses a collaborative predictor to infer which television programs the user would be interested in. Making Show Recommendations Using a Distributed Collaborative Filtering Architecture Amazon, iTunes, and an increasing number of other online retailers are currently incorporating similar schemes.

However, with the exception of the lowly junk-mail filter, non-retail information software that learns from history is still rare. Typically, users can only hope for last-value prediction, if that. Most software wakes up each day with a fresh case of amnesia.

And repeat it they will—tediously explaining their context, mouse click by mouse click, keystroke by keystroke, wasted hour by wasted hour.

This is called interactivity. Chris Crawford defines interaction as a three-phase reciprocal process, isomorphic to a conversation: Her partner then does the same. For manipulation software, interaction is perfectly suitable: It mimics the experience of working with a physical tool.

Information software, by contrast, mimics the experience of readingnot working. It is used for achieving an understanding—constructing a model within the mind. Thus, the user must listen to the software and think about what it says… but any manipulation happens mentally. For information software, all interaction is essentially navigation around a data space. For a yellow pages directory, the data space contains all business listings; for a movie guide, all showtimes and movie information; for a flight planner, trips to and from all airports.

This is simply navigation. Alan Cooper defines excise in this context as a cognitive or physical penalty for using a tool—effort demanded by the tool that is not directly in pursuit of a goal. For example, filling a gas tank is done to support the car, not the goal of arriving at a destination.

Cooper goes on to assert that software navigation is nothing but excise:. Except in games where the goal is to navigate successfully through a maze of obstacles, navigation through software does not meet user goals, needs, or desires. Unnecessary or difficult navigation thus becomes a major frustration to users.

If all interaction is navigation, and navigation is the number-one software problem, interactivity is looking pretty bad already. However, when compared with the other two sources of context, interactivity has even worse problems than simply being a frustrating waste of time:.

The user has to already know what she wants in order to ask for it. Purely interactive software forces the user to make the first move. The user has to know how to ask. That is, she must learn to manipulate a machine. However, Norman described this concept in the context of mechanical devices. It only applies to software if the software actually contains hidden mechanisms that the user must model. A low-interaction, non-mechanical information graphic relieves both user and designer from struggling with mental models.

Software that can be navigated is software in which the user can get lost. The more navigation, the more corners to get stuck in. Beyond these cognitive problems are physical disadvantages of interaction. The hand is much slower than the eye. Licklider described spending hours plotting graphs and seconds understanding them. A user who must manually request information is in a similar situation—given the mismatch between mousing and reading speeds, most of her time may be spent navigating, not learning.

Further, the user might prefer to learn information while using her hands for other purposes, such as writing or eating or stroking a cat. Finally, the growing prevalence of computer-related repetitive stress injuries suggests that indiscriminate interactivity may be considerably harmful in a literal, physical sense. Unless it is enjoyable or educational in and of itself, interaction is an essentially negative aspect of information software.

There is a net positive benefit if it significantly expands the range of questions the user can ask, or improves the ease of locating answers, but there may be other roads to that benefit. As suggested by the above redesigns of the train timetable, bookstore, and movie listings, many questions can be answered simply through clever, information-rich graphic design.

Interaction should be used judiciously and sparinglyonly when the environment and history provide insufficient context to construct an acceptable graphic. Interaction is merely one means of achieving that. The working designer might protest that interaction is unavoidable in practice, and may even consider my ideal of interaction-free software to be a scoff-worthy fantasy. This is only because the alternatives have been unrecognized and underdeveloped.

I believe that with the invention of new context-sensitive graphical forms and research into obtaining and using environment and history, the clicking and dragging that characterizes modern information retrieval will be made to seem laughably archaic.

When the user is forced to interact, the software assumes the form of manipulation software. However, alg forex genuine manipulation software, the user does not care about this model—it is merely a means to the end of seeing relevant information.

Assuming that graphic design, history, and the environment have been taken as far as they will go, there are a few techniques that can lessen the impact of the remaining interaction:.

Modern GUIs may be easier to use, but they are not much different in that respect. The GUI language consists of a grammar of menus, buttons, and checkboxes, each labeled with a vocabulary of generally decontextualized short phrases.

Two of the most fundamental context dimensions are where and when. For millennia, people have described these concepts with specialized information graphics. But much modern software abandons this tradition, as seen on the website of a popular moving company: These drop-down menus are awkward and uninformative. Geographical locations belong on maps, and dates belong on calendars. Even this is not ideal. But until platforms that enable such a thing are widespread, software can at least provide temporary ones.

As an example of more application-specific context, a prominent online flower shop lets the user narrow the view via a set of drop-down menus. Compare it with a simple visually-oriented redesign:.

Many types of context can be naturally expressed in some informative graphical domain, relieving the user from manipulating information-free general-purpose controls. Several more examples will be given in the case study below. If the software properly infers as much as possible from history and the environment, it should be able to produce at least a to trading in binary option with a minimum deposit 100 starting point for the context model.

This is generally less stressful than constructing the 97 trading forex systems context from scratch. For example, Google Maps offers both absolute navigation typing in an address and relative navigation panning and zooming the current map.

However, it initially displays by default the entire continent; this effectively demands that the user type in an absolute location to get started. A better design might start at the last place the user looked last-value predictionwith a nearby list of locations predicted australian dollar to euro conversion table history recently visited or manually bookmarked and the environment addresses extracted from email, open best stock trading simulator, and calendar software.

An even better design would recognize the prediction list as information software in its own right, and dunkin donuts stock ticker symbol take steps to show the data such as annotating the predictions with driving times to and from common locations, taking current traffic conditions into account and arrange the data perhaps spatially arranging the predictions on their own map.

Salen and Zimmerman offer a game design perspective on a principle that is crucial for all interactive software:. If you shoot an asteroid while playing a computer game and the asteroid does not change in any way, you are not going to know if you actually hit it or not. If you do not receive feedback that indicates you are on the right track, the action you took will have very little meaning. On the other hand, if you shoot an asteroid and you hear the sound of impact, or the asteroid shudders violently, or it explodes or all three!

This principle is universal. If the user clicks a checkbox and nothing happensher action is rendered ambiguous or even meaningless. She cannot evaluate a response and let it guide her next action. For information software in particular, all interaction specifies context. Thus, each interaction can and should result in a discernible change to a context-sensitive information graphic. Providing immediate feedback reduces the amount of manipulation the user must do before either reaching an adequate view or recognizing a wrong turn and backtracking.

Google Maps offers reasonable feedback during relative navigation, but none during absolute navigation, such as typing in an address. Because of the immediate feedback, the user can stop typing when she gets close enough, and use relative navigation from there. Much current software is interaction-heavy and information-weak.

I can think of a few reasons for this. First, our current UI paradigm was invented in a different technological era.

The initial Macintosh, for example, had no network, no mass storage, and little inter-program communication. Thus, it knew little of its environment beyond the date and time, and memory was too precious to record significant history.

Twenty years and an internet explosion later, software has much more to say, but an inadequate language with which to say it. Today, their windows and menus are like buggy whips on a car.

A second reason why modern software is dominated by mechanical metaphors is that, for the people credit default swaps trading strategies create software, the computer is a machine.

The programmer lives in manipulation mode; she drives her computer as if it were a car. Thus, she inadvertently produces software that must be operated like a machine, even if it sbi card rates forex used as a newspaper or book.

Worse, the people who design platforms and GUI toolkits are even more prone to this perspective, since they work at a lower level. The application software designer is then almost forced into a mechanical model by the design environment. Dynamic graphics, the cornerstone of information software, must be tediously programmed with low-level constructs. Even software that starts out information-rich and interaction-simple tends to accumulate wasteful manipulation as features are added over successive versions.

After ten versions, the software can grow into a monstrosity, with the user spending more time pulling down menus than studying and learning information. The design has clearly been successful. Even though the target audience is fairly small SF bay area public transportation riders with the latest Mac OS and knowledge of how to customize ituser feedback has been wildly enthusiasticand the widget received the Apple Design Award, as well as Macworld magazine's rare perfect rating.

If you are unfamiliar with the widget, you can watch a one-minute demo movie:. As information software, the widget was approached primarily as a graphic design project. I will discuss how its design exemplifies the viewpoints in this paper, and also point out where it falls short and could be improved. Thus, the widget does not reflect new ideas conceived while writing this.

The BART widget was designed around three classical forms of graphical communication: Information software allows the user to ask and answer questions, make comparisons, and draw conclusions. In the case of trip planning, some questions are:.

Users use the answers to compare the available trips, and draw a conclusion about which to take. Naturally, it must be possible for that conclusion to take the form of a plan: I will take the 7: A good design would also allow for a series of quick boolean conclusions over time: The choice of graphical representation depends on what sort of data space is left after context-based winnowing.

What context can be inferred? The user is expecting to leave around a particular time; thus, the graphic can exclude trips outside of some narrow time window. That is, the user wants to compare trips along the time dimension, but not the space dimensions.

After winnowing the data, we are left with a handful of trips—ordered, overlapping spans of time. We need a graphical construct that allows the viewer to compare the start, end, and length of each span.

A natural choice is a time bar graphwhich allows for important qualitative comparisons at a glance: How to make money driving a taxi cab does each span start and end? How long is each span? How close together are they? The time bar graph may have been invented by proto-chemist Joseph Priestly in to compare the lifespans of various historical figures.

Howard Wainer claims to have uncovered a bar graph from years earlier, plotting population changes in the tribes of Isreal after the exodus.

See Graphic Discoveryp The most important context, the current time, can be emphasized by shading the past. The most important data point, the next train, can be emphasized by keeping it in a constant location, the second row.

This answers the most important qualitative questions: Is the next train coming soon? Did I just miss a train? The graphic can then be unobtrusively annotated with quantitative information, so closer inspection answers all of the questions precisely:. Transfers can be regarded as segmentation of the overall trip. The question that must be answered exactly is where to transfer. The questions of when and how long should be answered qualitatively; the exact times would be irrelevant clutter.

In contradiction to the premise of interaction design, this software is at its best when acting non-interactively. Accordingly, all interactive mechanisms—the buttons and bookmarks list—are hidden when the mouse pointer is outside the widget.

Unless the user deliberately wants to interact with it, the widget appears as a pure information graphic with no manipulative clutter. Of course, if the predicted context is wrong, the user must interact to correct it. This involves navigation in the usual two dimensions, time and space.

The widget naturally stays in sync, always displaying relevant information. There are two cases in which this context is incorrect:. To see earlier or later trips, the user can simply drag the graphic around. A cursor change suggests this, as well as a brief message when the widget is first started.

Thus, a GUI scrollbar would be inappropriate. To plan around an sydney forex opening hours gmt time, the user clicks a button to reveal the hours of the day, from morning to night, laid out linearly. The user can then click anywhere on the mechanism to jump to that time.

This forces the user to keep her eyes on the information graphic, instead of wasting effort precisely manipulating the navigation mechanism. Instead of precise, tedious absolute navigation, offer quick ballpark navigation, followed by relative navigation in a tight feedback loop. Unlike the time of day, the predicted date today is probably close—few people plan subway trips weeks in advance. Thus, the date control is relative.

The assumed context includes where the user is coming from and where she is going. There are three cases for which the context is incorrect. The most common case is that the user is making a round trip, and wants to come home.

The second case is that the user is making a common trip, and knows exactly where she wants to go. The bookmarks feature serves this case. When the user clicks the heart buttonthe trip is added to a bookmarks list. From then on, that trip and its reverse can be selected with a click. No manipulation is needed to bring up the bookmarks list—it slides out when the mouse is over the widget.

In many cases, that would eliminate the need to even click on the bookmark. The most interesting case is the least common, but the most stressful for the user—selection of an unfamiliar station. The user needs information to decide which station to travel to; thus, this can be approached as an information software problem in itself. Some questions the user might have:.

These questions involve orientation what time does the asian forex market open gmt navigation in a physical two-dimensional space. The standard graphical device for this situation is the map.

This map courtesy of newmediasoup. Once the user has decided, she must indicate her selection to the software. This manipulation can be done in the same graphical domain as the information. Ideally, the map would always be visible.

A better design might then overlay dynamic information on the map, such as the positions of the trains and arrival times at stations. The widget can speak announcements of upcoming trains. Vocal announcements were originally a semi-hidden Easter Egg, but they got enough of a user response that they were moved up to first-class feature.

The design challenge is allowing the user to express if and when she wants announcements. A typical design would use a preference dialog or form that the user would manipulate to tell the software what to do.

However, an information design approach starts with the converse—the software must explain to the user what it will do. It must graphically express the current configuration. For presenting abstract, non-comparative information such as this, copy paste work from home without investment in pune excellent graphical element is simply a concise sentence.

As with the map, once the information graphic is established, manipulation can be incorporated. In this case, some words are colored red, and the user can click on these words to change them. The user always sees the software presenting information, instead of herself instructing the software. If the information presented is wrong, the user corrects it forex meta trader place.

The graphic fades out when the mouse is clicked outside of it or the mouse leaves the widget. This approach scales well to more complex configuration. The widget allows spoken announcements to be associated with a bookmark and a particular time. This is useful for daily trips, such as to and from work. Sentence-based configuration scales so well because parameters are given meaning by the surrounding textual context, which can itself consist of other parameters.

A typical configuration dialog box attempts to express each parameter in isolation, resulting in intimidating or bewildering verbosity: But surely these people were parsing and producing complete sentences long before they could manage a dialog box.

The human brain actually does have some hard-wiring. Some additional graphical touches help bring the design together. The sentence is contained within a cartoon speech bubble which, beyond simply looking cute, implies that the activity pertains to speech, and points via the tail to the button which spawned it and the trip to which it refers.

The trip planner on the official BART website refuses to divulge any information whatsoever without a sequence of menu selections and a forex az turkey. Because the BART system is two-dimensional, no linear arrangement of the stations can convey useful information.

The user can click a link to see a map, but the map graphic is static; the selection must be made through drop-down menus. Information and navigation are completely segregated, and the feedback loop is enormous.

The starting and ending stations, always the same, clutter the results. Transfers are treated as two separate trips, and the relevant times the start and end of the entire trip are in opposite corners, with distracting clutter in between. Not only does the information not stay in sync with the current time, there is no relative time information at all.

For all its interactivity, the international stock exchange brokers in karachi here is sparse, poorly presented, and hard to get to.

Yet, this sort of design is so typical of software on all platforms, it has almost become an accepted norm. Ironically, the BART widget appears so fresh forex tester 2 indicators its underlying ideas are so old. The time bar graph was invented about years ago. The map and the written sentence are both about years old. They are beautiful, venerable forms of visual communication.

The bugs have been worked out. They are universally, intuitively understood. The pulldown menu, the checkbox, and the bureaucracy-inspired text entry form were invented 25 years ago, desperation devices to counter inadequate technology. They were created for a world that no longer exists. Good information software reflects how humans, not computers, deal with information. The airline industry, on the other hand, has every incentive to give customers a smooth decision-making experience.

However, planning a trip through the sky is almost identical to planning one underground. Additional columns to the right are not shown. The times and lengths of the flights, and the count, times, and lengths of stops and transfers, can be compared visually. Trips without transfers stand out because they are entirely blue; non-stop flights would appear unbroken. Anomalies, such as the 6: Times can be converted into either time zone simply by referencing the appropriate header bar.

There is some attempt to use color symbolically. However, it is not critical that the user notice this. Interaction is simplified to the point where a short, instructive sentence can describe each and every click. At the most, the user will click twice on the map, when to buy stocks vs bonds across the calendar, and click twice on the ticket prices, possibly with some page scrolling.

Last-value prediction automatically selecting the last route purchased, and displaying a list of recent trips may eliminate or reduce the map clicks for many travelers. A learning predictor, capable of inferring that the user always spends the first Monday through Friday of the month in Baltimore and selecting that range on the calendar automatically, could eliminate all context-establishing interaction, leaving only the decision-conveying interaction of clicking ticket prices.

Of course, since everything is on the same page and feedback loops are tight, the user can explore different dates and cities, and see the available flights immediately. With air travel in a slump for the past few years, airlines have been desperate for any passengers they can get. Unsuccessful ones have even faced bankruptcy. The problem is primarily cultural. Mass production of machines emerged at the start of the 20th century. But many of these products were unpleasant to interact with.

Within a few decades, a new profession arose to fill the gap—industrial design. The next revolution in the mass production of machines was software. The late s saw the rise of the personal computer, a device capable of behaving as any machine—typewriter, adding machine, filing cabinet, arcade game—when given the right instructions. But much of this software was unpleasant to interact with.

Within a couple decades, a new profession arose to fill the gap—interaction design. The mass production of information has a very different history than the mass production of machines. Industrial design brought art to existing mass-produced technology, but printing brought mass-producing technology to an existing art.

Before the 15th century, books were precious and extremely rare, for each had to be copied by hand. A single book might cost as much as a farm. Books were also exquisite works of art, carefully lettered in calligraphy, lavishly illustrated and decorated. Fortunately, Gutenberg and contemporary printers were exceptionally devoted to the art form, and took great pains to preserve the quality of the hand-lettered page. When people noticed the quantity and similarity of the books, they did not suspect printing, but witchcraft!

The explosion of new books of all kinds, as well as the rise of the broadside precursor to the poster and the newspapercreated a great demand for artists in the new medium, many of whom transitioned from the old medium. The art of laying out a page eventually became known as graphic design. The next revolution in the mass production of information was the web. Unlike early printers, unfortunately, early web technologists cared little for the artistic qualities of their predecessor, but the capabilities eventually evolved to approximate the printed page on the computer screen.

Publishing was now just a matter of sending bits through a wire.

Apply For Centum Investment’s Graduate Trainee Programme (K) - Jobs in Kenya - ronoxivipyr.web.fc2.com

The explosion of websites created a great demand for artists in the new medium, many of whom transitioned from the old medium. The art of laying out a webpage became known as web design. These parallel evolutions have produced designers for interactive machines conventional software and designers for static page layouts conventional websites. From this viewpoint, the chimeric effects of convergence are almost to be expected.

Information is trapped behind interactive mechanisms and presented in static layouts—it is the worst of both worlds. Good context-sensitive information graphics are neither interactive nor static, neither machines nor page layouts. Design has not evolved to produce them. The culture is blind to the possibilities. The first step toward the information software revolution is widespread recognition of the need for design.

It must be universally understood that information software is not a machine, but a medium for visual communicationand both publishers and public must hold it to the same standards that they hold print. People constantly settle for ugly, clunky software, but demand informative, professionally-designed books, newspapers, magazines, and—ironically—brochures, ads, and manuals for that forex illumination signals system free download software.

Though once justified h t pawnbrokers stockport technological limitations, this double standard is now dangerously obsolete. It is the first and largest obstacle to revolution.

Without consumer demand, design appears to give no return on investment. I see the opposite—as technology races ahead, people are tolerating increasingly worse design just to use it. The most beautifully-designed DVD player will go unsold if the competition costs the same and has S-Video output, or plays MP3s from memory sticks.

Good design makes people happy, but feature count makes people pay. At a time when many products competed on ornamentation, the simplified, functional creations of industrial designers were too untraditional to sell on looks alone.

The salesman made inroads by directly touting the tangible benefits of good design, such as comfort and safety. He would demonstrate to a homemaker how his vacuum cleaner or iron was designed to reduce fatigue and cramping. He would demonstrate to a farmer how his machinery was designed to eliminate the finger-severing accidents that were, to that point, distressingly common.

Explicitly informed of the benefits, people gradually came to demand, then expect, such conscientious design in their everyday products. Other factors that boosted industrial design were fashion top designers were promoted as celebrities and price good 97 trading forex systems often lowered manufacturing and materials costs. Both factors can be applied to software.

Today, software consumers demand technological features because software marketing presents features. Consumers ignore design because marketing ignores design. The cycle is vicious, but perhaps vulnerable too—some brilliant new software with engineering, design, and marketing all in sync may top 5 forex robots the bar for everyone.

The second step toward the information software revolution is finding people with talent for visual communication. Currently, almost all software is designed by people who are very comfortable with computers; their interest in technology motivated them to enter the field. This suggests an enormous exclusion of potential talent—imagine if all graphic designers had to be comfortable running a print shop!

I believe that ideal candidates for software design are those who have achieved mastery of information graphics in other mediums. There may be multitudes of how much money does a chiropractor make in california, currently drawing business graphics or maps or comics, who could excel weeworld money generator information software design if they had any idea that it was a legitimate artistic field.

Recent years have brought a wealth of beautiful amateur websites, created by visually-oriented people dabbling in the only sort of software design accessible to them. Skill is achieved through education and practicebut dearth of the former has given aspiring designers no entry point—they are expected to learn the art through osmosis deep discount stockbroker guesswork.

Effective education can entail any, but ideally all, of: The renowned Art Center College of Design in Pasadena offers forty courses in industrial design. Students learn art theory, draftsmanship, and visual communication theory.

They learn about form, and the visual and tactile properties and constraints make money spamming forums materials. They learn about cognitive and behavioral psychology, and explore how users experience products. They follow the entire production process: They learn to devise artistic solutions to problems, to think creatively and think critically, to invent concepts and critique those of others.

They interact with industry representatives and do team projects under corporate sponsorship. Art Center offers only five courses that could be somewhat related to information software. Interactive StructuresInformation and InteractivityBranding and InteractivityInteractive Design 1and Interactive Design 2.

For the most part, students learn to make websites. There is nowhere copy paste work from home without investment in pune the breadth or depth offered to designers of physical products. Art Center clearly knows how to put together an applied arts curriculum. Experimental analysis can be valuable, but only if an artist has created a design worth analyzing. Information software design will need a body of pedagogical literature, once enough theory is developed to make pedagogy possible.

The paucity of literature on information graphic design is bewildering. They have exchange rates malaysian ringgit to usd little company to define a category. I doubt you will find either in a bookstore. The shortage of good books on user interface design is more understandable, since pedagogy requires a working paradigm—the status quo must be at least acceptable.

For the field to progress, we need less recycled platitudes and more cutting-edge research. The industrial design literature, incidentally, seems to consist primarily of photographs of chairs.

In all artistic fields, from painting to writing to music to architecture, students study the works of the masters. Much has been written about the failure of software engineering schools to provide examples of great works, expecting students to somehow derive style from first principles. Engineering study typically focuses on how something should be done, not how it has been done, to the detriment of the culture.

But a corpus is crucial for the development of any artistic field. Outstanding designs must be recognizedcollectedand explicated. Furthermore, outstanding designers should be recognized and encouraged to teach, instead of hidden behind a corporate label. These two terms are vague in common usage. I will define a tool as a communication device that a designer has control over, and a platform as a communication device that a recipient is expected to dm bz wbk forex. A tool encodes mental information into physical datawhich can travel in a physical medium.

Ffxiv arr fastest way to make gil platform decodes the physical data into the mind of the recipient. Because all information transfer short of telepathy requires some medium, this model is universal. If I write you a letter, my tools are pen and paper, and your platform is knowledge of my forex trading hours during christmas language.

If I broadcast a radio signal, my tools are a microphone and transmitter, and your platform is a radio receiver. In general, my tools are whatever I use to make the thing I hand off to you. To deliver her message most effectively, the visual designer needs as much control as possible over what the viewer sees. But, by definition, the designer only has direct control over the tool.

She is at the mercy of whatever platform implementation the recipient happens to supply. This implies that a good platform must be as simple and as general as possible. One way is to make it so simple that there are obviously no deficiencies, and the other way is make it so complicated that there are no obvious deficiencies.

From a practical and historical standpoint, we can assume that no complex specification will be implemented exactly. This, in itself, is not a problem. However, multiple, decentralized implementations of a complex specification will be incorrect in different ways.

A platform dia trading signals of the union of all possible implementations is thus arbitrarily unreliable —the designer can have no assurance of what a thumbhole stock savage mark ii actually receives.

For a platform to be reliable, it must either have a single implementation, or be so utterly simple that it can be implemented uniformly. If we assume a practical need for open, freely implementable standards, the only option is simplicity. In each case, the power of the platform is effectively constricted to some simple, reliable subsetand enormous time is wasted designing around incompatibilities.

By contrast, JPEG, MP3, and modern CPU instruction sets are universally dependable, because much of the complexity is placed reliance call put option the encoding tool, not the decoding platform.

Almost a century ago, a similar justification was used to reject single-sideband public radio. The complex Perl and Make money with camtasia platforms are dependable only because they have centralized implementations. In order for a designer to take full advantage of the medium, a good platform must provide safe access to everything that is technologically possible.

A platform for information software must offer: Anything less robs information software of its full potential. Alarmingly, the latest platforms forgo both of these virtues. CSSa language for specifying visual appearance on the web, is a particularly egregious example.

It is so complex that it has never been implemented correctly; yet, successive versions specify even more complexity. At the same time, it is so underpowered that many elementary graphic designs are impossible or prohibitively difficult, and context-sensitivity or biggest market losers stocks computational must be addressed externally. Most CSS lore is dedicated to describing the tangles of brittle hacks needed to circumvent incompatibilities or approximate a desired appearance.

For universal reliability, the ideal platform must be optimized for ease of implementation. Thus, the tool and platform cannot be the same—we 97 trading forex systems expect a layer of translation between what the designer works with and what the platform interprets. This considerably eases implementation of the processor, although the motive in this case is more performance than reliability.

If a particular tool is implemented incorrectly, the designer can work around its particular idiosyncrasies, or switch to a different tool. It is much easier for a designer to switch or upgrade tools than for a sea of users to switch or upgrade platforms. The platform must make it possible to create information software.

The tool must make it easy. A specific look at some tools and platforms for information software will be offered in the next few sections. The fifth and final step into the information software revolution is an environment where experimentation, evolution, and interplay of ideas can thrive.

Much like our geological environment, a creative environment can become fatally polluted by short-sighted business interests. Beforeauthors invariably presented quantitative data as tables of numbers. In this year, an economist named William Playfair published a book called The Commercial and Political Atlas.

In order to illustrate his economic arguments, Playfair single-handedly invented the line graph, the bar graph, and the pie chart, and thereby the entire field of statistical graphics. Within years, his inventions had spread across Europe, transforming the landscape of visual communications and heralding an age of discoveries in data made visible.

Today, children take these graphical forms for granted; they seem as obvious and fundamental as written language. Imagine if Playfair had patented his invention and prosecuted his imitators, suppressing the crucial period of initial excitement and growth. Would we today be staring at tables of numbers, unable to apply our visual cortex to unlocking their patterns?

This path is inevitablefor it is the path of all artistic media. Books, newspapers, and the static visual arts have already completed it, or almost so. Movies, television, and published music are struggling at step five, but completion is only a matter of time. For information software as well, it is only a matter of time. But a decade or a century? Of course, design is nothing without implementation.

If information software is to consist of dynamic graphics that infer from history and the environment, it must be possible and easy to create such things. The following sections will discuss a design tool for dynamic graphics, and engineering approaches to inferring from history and the environment.

Software tools for drawing static graphics or composing static animations have long been commonplace. But the designer who wants to create dynamic graphics—graphics whose properties are data-dependent—currently has two undesirable options:. She can learn some sort of programming language. Many designers are intimidated by engineering and may lack the talent or desire to program.

They are completely justified— drawing is a visual activity, and working with textual abstractions is entirely inappropriate. Painters, illustrators, and sculptors manipulate the artifact directly—there is no abstraction, and visual feedback is immediate.

With the growing popularity of the clavier and harpsichord, and then the piano, it became acceptable for composers to hear their creations as they composed. Most of our classical masterpieces were composed in this way. Today, not only is every composer expected to work at an instrument, illiteracy is even becoming acceptable! Alternately, a designer can draw a series of mockupssnapshots of how the graphic should look for various data sets, and present these to an engineer along with a verbal description of what they mean.

The engineer, who is skilled in manipulating textual abstractions, then implements the behavior with a programming language. This results in ridiculously large feedback loops—seeing the effect of a change might take a day instead of a second.

This is no environment for creative exploration. There is nothing wrong with the concept of drawing mockups. It is a natural, visual way to work, and is ubiquitous across many artistic disciplines, from architecture to industrial design. The problem lies with engineering the behavior the mockups describe. But, consider what exactly the engineer does. From a set of mockups, the engineer infers the pattern they conform to—how the graphic changes as a function of the data—and codifies this inferred pattern in a computer program.

Is a human really necessary? Both are compendia of research projects, not textbooks. This field is concerned with teaching behavior to a computer implicitly, through a series of examples, rather than with explicit instructions. Researchers have created systems with varying degrees of success for constructing interactive GUI widgets, defining parameterized graphical shapes, moving and renaming files, performing regular expression-like text transformation, and other domain-specific tasks.

With these systems, the user typically performs a few iterations of a repetitive task manually, and the system then performs the rest according to an inferred generalization, perhaps asking for clarification or confirmation. This section outlines a hypothetical but plausible tool to allow designers to create dynamic data-dependent graphics with no conventional programming.

These dynamic graphics would serve as the user-facing visible representation of information software. The tool can be considered an extension of a conventional vector-oriented drawing program. The necessary feature is the representation of graphical elements as objects with variable properties, rather than as arrays of pixels. Using the same drawing process as with a conventional tool, the designer draws a mockup of the graphic—how the graphic should look for some particular set of data.

She then takes a snapshot of this graphic, and indicates the data set that it corresponds to. She then modifies the graphic to correspond to a slightly different data set, takes another snapshot, and so on. Each snapshot serves as an example. With well-chosen examples, the tool will infer how to generate a graphic for arbitrary data. This tool is significantly less ambitious than many in the literature, for several reasons:.

I will demonstrate how we might use this tool to design the BART widget described above. We start by modeling a single train bar. This graphic has a number of dynamic aspects: For now, we will just handle the color and label. We draw a picture, take a snapshot, and indicate the data properties that it corresponds to:. Compare these two snapshots. The tool will learn and use this rule, provided no other example contradicts it. The graphics in the new snapshots are exactly the same as the orange-line Richmond-bound example, except for hue adjustments.

How we know that it has learned correctly will be discussed below. If we want to clarify the model for posterity, we can add visual comments simply by drawing outside the snapshots:. We will use two data properties.

Here are our first two snapshots:. The second row is more problematic. The tool infers linear relations when given two points, so our examples indicate this relation:. The three snapshots give us these constraints: This gives us the following relation, with interpolation in black and two possible extrapolations in red and blue.

The blue extrapolation is desired. The tool can probably infer it, since it results in an arguably simpler relation. But if the tool infers incorrectly, the designer can easily correct it. How so will be discussed below. Time extends infinitely; thus, the timeline is conceptually an infinitely-wide bar. Of course, only a portion of this bar is actually visible at any given instant. Dealing directly with infinite graphics will be discussed below.

Here, I will demonstrate how this can be easily simulated with a normal graphic. The red box indicates the clipping region of the graphic. The section within the box is the portion that will actually be visible. These snapshots differ from each other in only two aspects: We can see that the clipping region slides rightward with time, snapping back to the left on the half hour.

The cyclic extrapolation can either be inferred by the tool or specified by the designer, as will be explained below. The rest of the labels will be inferred similarly. Next, we combine some of the components created above to form a compound component:.

Adjacent pairs of snapshots describe how to adjust, respectively, the end point of the Trainthe start point of the Trainand the clipping region:. Notice that adjustments were made within individual components. The length of the Train was changed, and the second When was right-justified.

These links are not shown here. We are almost done. We have to put the title together:. No inference is used here; we explicitly link the properties to the appropriate labels. Finally, we are ready to lay out the top-level component.

We draw the background picture and place the components created above. No inference is used here. We explicitly link the top-level properties to the appropriate component properties. Our dynamic graphic is complete. The final program would consist of this graphic and a data source that fills in the properties. Of course, this small example does not entirely emulate the actual BART widget, but it is easy to see how additional features can added, simply with models and snapshots. It is also easy to see how a completely different design, such as the tables on the official BART website, could be composed on top of the exact same data source.

The essence of this process is elimination of abstraction. The designer works with concrete, visible examples. However, this raises a concern about editing. An advantage of abstraction is that it localizes common properties, so widespread changes can be made with a single edit.

What if the designer decides that a Train should have square corners instead of rounded? Having to individually edit each of the snapshots is unacceptable—such a burden would squelch experimentation. Instead, the designer simply selects the snapshots she wants changed, and proceeds to edit one of them. The changes propagate to all selected snapshots.

This is possible because the tool treats the snapshots as variations on a single graphic, rather than independent graphics. A more quantitatively-oriented designer may prefer to manipulate inferred relations directly. Mapping curves can be shown graphically, and the designer can move anchor points around, add new anchor points, and introduce curvature by stretching the interpolation curves.

This allows for non-linear or nuanced behavior that would be difficult to specify purely with examples. The curves are an abstraction, but because it is purely visual, designers may find it comfortable. To lessen the abstraction, abundant concrete examples from along the curve are shown, and a designer can point anywhere in the plane to see an example that corresponds to that point. Conventional software engineers will be worried by the rampant ambiguity in this design process.

In the demonstration above, the snapshots are visible but the inferred relations tying them together are not.

Unlike a programmer typing into a text editor, the designer does not create these snapshots in isolation. The tool provides a design environment that actively communicates the dynamics of the graphic.

One approach is for the tool to directly ask the designer about ambiguous cases. The tool can present the designer with a data set that would disambiguate an unclear relation, and the designer would then draw a snapshot for that particular data set. We might imagine the design process becoming inverted, driven by the tool—the designer would create a few representative examples, and then let the tool explicitly ask for all of the examples necessary to fill out the model.

However, visual art has traditionally been composed actively, not reactively, and this approach may feel unnatural and stifling. A more natural and information-oriented approach uses continuous peripheral feedback. The tool adorns the screen with an array of its own examples that represent the inference it currently understands.

As the designer works, she can visually verify that the inferred relations are correct:. The tool can graphically emphasize feedback examples according to how little confidence it has in them. If one is incorrect, the designer creates a new snapshot simply by clicking on it and correcting it. In addition to feedback through examples, the mapping curves described above also provide feedback.

As the designer creates snapshots, she can see the inferred curves. If an inference is incorrect, she can either create more snapshots, or directly edit the curve as long as the tool has correctly inferred which variables are involved in the mapping. If the tool feels an extrapolation is ambiguous, it can display all of the candidate extrapolations on the curve, and the designer can select one with a click:. If necessary, the designer can add hints to encourage the tool to prefer certain inferences.

There are two types of hints: A dependency hint suggests that a particular graphical aspect is related to a particular data property. The specific mapping between the two must be specified through examples or curves, but this hint tells the tool which variables are involved. A constraint hint suggests that a particular graphical aspect is related to some other graphical aspect.

In the example below, we ensure that the train cannot shrink smaller than the text label, by constraining the right edge of the train to lie to the right of the label:. The example below models a character whose eyes will watch the train, wherever it goes. The eyeball is hard-constrained to lie within the eye, and soft-constrained to move as close as possible to the train. Hints may allow a designer to specify complex relationships that would be difficult to describe purely through snapshots.

In the demonstration above, an infinitely-wide timeline bar was modeled by cyclicly panning over a finite graphic whose labels change on each cycle. This corresponds to the computational concept of iteration. An alternative for modeling infinite graphics is recursion.

This Timeline component contains a Timeline component, shifted right by pixels. The graphic now must be infinitely wide, because it is pixels wider than itself. With each paste, the yellow box shifts over by pixels, and the pasting could go on forever. Now, we edit the text labels in the first paste indicated by red arrows:. As we do so, the tool infers a linear relation between the top-level label That is, the tool learns to add a half hour each time it pastes.

The result is a timeline whose labels increment forever. Some may claim that recursion is inappropriate for graphic designers. I believe that, with training, any designer who appreciates MC Escher can learn to make powerful use of visual recursion. One of the primary benefits of this tool is the freedom it gives designers in composing the appearance of information software. Unless complex behavior is necessary, the engineer is completely uninvolved with graphical presentation, to the relief of both designer and engineer.

For example, in the actual BART widget, the ending times become left-justified if the trip is too short:. Excellent software is characterized by this sort of attention to detail. However, if a designer were to request that this minor feature be implemented, she would probably be rebuffed by both engineer and management. This tool allows a perfectionist designer to add this feature on her own, just by taking a couple additional snapshots.

Interested or skeptical engineers are encouraged to read the two machine learning books cited immediately below, as well as the two Programming By Demonstration books cited above. Good information software will attempt to predict current context by discovering patterns in past contexts. Although such application software is rare, there is nothing novel or exotic about the algorithms required.

A Modern Approach covers learning within a much broader context, but is less focused and concise. Consider the example presented earlier of a train trip planner that predicts the route that the user wants to see. A planner that models these patterns could automatically present the user with appropriate information, eliminating most interaction.

As a demonstration, I implemented this behavior with the very simple probabilistic algorithm described below: Each time the user indicates interest in a particular route, it is recorded in a history with the date and time. The user indicates interest either by explicitly switching the planner to display a route, or by looking at the planner and then looking away, indicating that the shown route is still interesting. If the time is 9: What the user did at Thus, each vote is weighted by a window around the time of the history entry.

She will glance at the planner frequently over a span of time. Each of these looks should not count as an individual vote. Instead, the entire span of checking is coalesced into a single history entry, with a widened time window. Also, throughout these frequent check-ups, the user sees only last-value prediction.

Learning prediction is only used if some time has passed since the previous look. Day of the week. A user will typically exhibit a superposition of daily patterns, such as going to and from work, and weekly patterns, such as cello practice every Tuesday. To allow for both, history entries from a different weekday are allowed to vote, but have a smaller weight. The bleed across days allows the algorithm to learn daily patterns faster, but because other days are penalized, weekly patterns can be learned as well.

Saturday and Sunday are independent from weekdays and from each other. Older history entries are given less weight, and eventually are forgotten. This makes the algorithm adaptive. If the user adopts a new pattern, such as switching jobs or joining the Thursday-night knitting circle, the algorithm is able to keep up, instead of having to be manually reset. Finally, the most recent route is given a bonus vote.

This causes the algorithm to default to last-value prediction if there is no compelling reason to do otherwise. I tested this algorithm with user models that simulate a variety of schedules. For a user who simply uses the planner to go to and from work, the algorithm learns the pattern flawlessly within a week. When the user switches schedules, the algorithm adapts within a couple weeks. The simulated times are normally distributed around the base time shown in the schedule, with a standard deviation of half an hour.

Up to a certain level, random unscheduled behavior can be added without the algorithm losing the pattern. Obviously, the random views are always mispredicted. In conclusion, it appears that this algorithm would successfully be able to infer the context of a regular user, allowing relevant information to be presented with little or no interaction. As an ad-hoc solution to a particular problem, this algorithm seems to work quite well.

As a general solution, it is no solution at all. This simple, understandable example was intended to demonstrate that learning prediction is not science fiction—it is a viable and powerful approach to context inference, one that every software designer must keep on her palette. However, the best learning algorithms are considerably more complex than this one. Currently, machine learning is considered an experts-only area, where the fruits of research are restricted to specialists.

Implementing learning behavior typically involves calling in an expert, not assigning it to the application programmer. Unfortunately, an algorithm that can only be wielded by a master is almost worthless. There are far more applications than experts; if application programmers cannot make use of learning, learning applications will remain rare and exotic.

This predicament has been overcome many times before. All software today performs an intricate dance of feeding a processor primitive machine-level instructions, repolarizing tiny magnets in hard drives, transmitting bits reliably across wires, and lighting up specific pixels on a screen. The algorithms behind these operations are unimaginably complex, requiring years of study. Yet, even novice programmers have no trouble with these operations.

The complexity has been hidden behind abstractions. In front of the abstractions are armies of application programmers, blessedly able to take all this for granted. As I see it, the primary challenge for the machine learning community is not the generation and tuning of yet more algorithms, but the design of simple abstractions. Learning magic must be packaged. It must be so simple that it can be taken for granted. Today, a Perl programmer needs just four letters to invoke decades of research into filesystems and physical media: The hardware-related sources, such as clocks and location sensors, might have seemed obvious.

The software-related sources, such as other information software and documents created with manipulation software, might have seemed so far-fetched as to be implausible. This section will present the information ecosystema software architecture which might allow for such behavior.

I receive an email from a friend. After reading the email, I open my map software to find that nearby pizza restaurants are prominently marked. One approach is to build a system that directly performs the desired behavior.

In this case, perhaps one would design an email program with a built-in map. The system described is a trivial solution to a general problem. What about information from a website showing up on my calendar?

The possibilities grow combinatorially—it is impossible to deliberately handle them all. Monolithic systems are bad for users. Email and maps are distinct concepts. There is no reason why a user should turn to the same software package for two unrelated purposes. Also, the components of integrated systems tend to be of lower quality than their dedicated counterparts. Monolithic systems are bad for software providers. In a healthy marketplace, whether of groceries or auto parts, individual providers offer components which combine with others for a complete solution.

A small software provider could provide an excellent email program, or an excellent map. But only a large corporation has the resources to develop an integrated package.

What we need, then, is not a system that implements this behavior, but a platform that enables such a system to grow organically, via small contributions from diverse providers. In forsaking integration, however, we forsake designed coordination between components. The email program and the map will be designed by two different software providers, oblivious to one another.

The programs must somehow exchange information without knowing anything about each other —without even knowing the other exists. As it happens, such a mechanism has long existed for manipulation software—copy-and-paste. This mechanism uses the platform as an intermediary. The drawing and word processing programs know nothing of each other—they know only of the platform and standard data exchange formats.

As befitting manipulation software, copy-and-paste requires explicit manipulation by the user. Information software must be able to share information implicitly and autonomously, with no user interaction.

An email is not a map location. Nor is a website a calendar event, nor a word processing document an encyclopedia entry. The information must be translated from one form to another. Given that this platform exists to promote inference from the environment, let us take some inspiration from a biological environment.

The very essence of a biological environment is autonomous translation. Plants translate sunlight into fruit, large animals translate fruit into dung, small animals translate dung into soil, plants translate soil into fruit. An ecosystem is a network of individual components which consume nutrients and translate them to an enriched form consumed by others, autonomously and with no knowledge of the system as a whole. The components above the platform are views.

This is the software that the user sees and interacts with. Views interact with the platform in two ways:. Views nominate a topic of interest. For example, if the user is reading an email, she is probably interested in information related to the contents of the email.

The email program would give the email to the platform as a topic. Views request topics of interest, of some particular type. The map, for example, would request topics that have a geographical location associated with them. If a restaurant were a topic, the platform would give it to the map, and the map would display it. The components below the platform are translators.

The platform gives them information objects, which they convert from one type to another and return to the platform. The platform itself acts as an intermediary between components, attempting to fulfill requests by constructing a chain of translators to convert topics into the requested types. Although it is clearer to visualize the process as described, an actual implementation would have to be lazydriven by demand.

This is necessary for efficiency reasons, but also explains how EpicurioCity knows the area to look for restaurants—the map actually requests objects with locations around a particular areaand EpicurioCity then attempts to produce objects that match this type. It also explains how EpicurioCity knows how many objects to produce from its almost infinite collection—it produces objects as long as the map consumes them.

Surely the last word typed would be nominated as a topic. It would then get picked up by EpicurioCity and translated into restaurants, and these would show up on the map.

This sort of emergent, non-designed behavior is the overall goal of the platform. The problem is addressed by recasting the question more fuzzily: Every topic is nominated with a level of confidence. When I finish reading it and move on to something else, its confidence diminishes. Translators produce dilution of confidence.

The text digester will have more confidence in unusual, prominent words, and words that seem related to other topics or the context in which topics were found. Partial or tenuous matches can be translated with low confidence instead of omitted.

For example, a movie translator from CelluDroid. Views, such as the map, use confidence to determine the graphical emphasis of displayed objects. This is a critical part of the graphic design. Beyond simply adjusting size, emphasis can involve all sorts of standard graphical techniques—contrast, color saturation, shading, shadowing, grouping, or placement on a different graphic entirely. Objects with confidence below some threshold will probably be discarded. As events cause confidence levels to change, the changes propagate through the chain of translators, adjusting the emphasis of displayed objects.

The next problem with this system is inappropriate translations. This would be a nuisance if it occurred every time I received an email from my friend. The problem is addressed through backpropagation of feedback. Feedback can be either explicit or implicit. Explicitly, I can indicate to the map that I am uninterested in dude ranching.

This negative feedback is returned to the AgoraBiblia. Implicitly, simply looking at the map without indicating interest in the dude ranch will cause a slight negative feedback, resulting in its de-emphasis over time.

On the other hand, if I frequently click on pizza places, positive feedback will backpropagate through the chain of translators, increasing confidence in all things pizza-related and resulting in their emphasis on the map.

In effect, the entire environment becomes a learning system, tailoring itself to the individual user.

The last problem I will consider here is the political issue of protocol creation. Just what is a Restaurant object, and who decides that?

Standards, especially premature ones, stifle invention and progress, but anarchy results in incompatibility. It may be possible to address this problem through namespacing and published proprietary protocols. To answer the above question, there is no Restaurant object. Instead, EpicurioCity produces a com. This proprietary object can be composed of other proprietary objects, as well as some standard objects defined by the platform, such as TextKeywordand Location.

Note that this proprietary Restaurant is not hindered from showing up on the map, since the map will accept anything with a Location and presumably some other standard properties such as a name and description. Restaurant conforms to the Mappable interface, and the map requests Mappable objects.

If the Restaurant happens to define enough standard properties, it can be mapped. A restaurant guide view, on the other hand, would be written to take advantage of the extra information that com. Restaurant offers—ratings, reviews, and such. When another provider, CuisineCousins. This makes their new translator immediately compatible with existing views. Meanwhile, the translator can simultaneously offer their own objects, such as a com. If a de facto standard emerges and stabilizes, it might eventually get canonized as the official Restaurant object.

Even then, though, providers will be able to add proprietary namespaced extensions to it. An obvious benefit to this platform is that it enforces modularity between data and views. Unlike current systems, in which almost all data and functionality is locked up behind a user interface, every service on this system is available to every view.

More subtly but just as importantly, the fact that translators have no end-user interface means they can be created by engineers. Only the views must be designed for users. Meanwhile, a designer who is dissatisfied with a view can simply create and release a replacement, with no engineering worries about data acquisition.

Because the system can be easily improved without cross-disciplinary concerns, creativity and invention should flourish. Culture changes much more slowly than technological capability. In a world where science can outpace science fiction, predicting future technology can be a Nostradamean challenge, but the responsible designer has no choice. A successful design will outlive the world it was designed for.

With what artifact will the people of tomorrow learn information? I believe that in order for a personal information device to be viable in the long term, it must satisfy two conflicting criteria: We have the technology to manufacture page desk-sized tomes, but despite the high information content, such books are rare. As people increasingly expect information on demand, portability will become ever more critical. Like a wallet and keys, the computer will be dropped into the pocket or purse before leaving the house.

This implies light weight and small volume. Consider again the book. We have the technology to produce books smaller than a business card, but despite the improved portability, such books are also rare.

The supremely-portable postage-stamp-sized book is non-existent. Although technology miniaturizes, the human eyespan remains a fundamental constant. Anything less cannot be read and skimmed comfortably, and cannot support spatially-distributed information graphics. To resolve these contrasting size constraints, I predict a computer the size and thickness of a sheet of paper. Like paper, its entire surface is a graphical display.

When in use, it is rigid; when not in use, it collapses and can be folded or rolled up or crumpled! Consider the capabilities relevant to context-sensitive information graphics: To serve as a book, the device must have a sufficiently large reading area and high pixel resolution.

To serve as a computer, the device must produce dynamic color graphics. Dynamic graphics with print resolution will open up a world of possibilities for detailed information graphics which are impossible today in either medium. Assuming a sufficient networking model, the device will be able to sense an enormous amount of information from the environment—geographical location, physical surroundings streets, stores, transportation options, entertainment optionssocial surroundings friends, strangers with interests in common, strangers who can serve a needand more.

Since its inception, electronic storage has exponentially increased in density and decreased in cost. But, perhaps more importantly, ubiquitous network access will make memory effectively unlimited. The device will have the means to remember everything the user has ever done and every environment in which she did it.

Touch or motion-based manipulation is somewhat more efficient than the mouse. Eye-tracking and speech may be better still, although even these are unlikely to match the order-of-magnitude improvements predicted for the capabilities above. But none of these mechanisms will ever approach the sheer amount of information that can be absorbed by the eye.

No matter what new interactive technology comes along, the bandwidth between the device and the user will remain not merely asymmetric, but utterly lopsided. Interaction is already a bottleneck. It will get much worse as graphics, environment, and history experience their expected breakthroughs. To me, the implication is clear—the principles of information software and context-sensitive information graphics will become critical as technology improves.

Are we preparing for this future?

I look around, and see a generation of bright, inventive designers wasting their lives shoehorning obsolete interaction models onto crippled, impotent platforms. I see a generation of engineers wasting their lives mastering the carelessly-designed nuances of these dead-end platforms, and carelessly adding more. I see a generation of users wasting their lives pointing, clicking, dragging, typing, as gigahertz processors spin idly and gigabyte memories remember nothing.

I see machines, machines, machines. I expect that designers who cling to these models will appear to the next generation like classical physicists as the world turned quantum, like epicycle-plotters as Kepler drew ellipses, like Aristotelians as Galileo stood atop the tower at Pisa. No matter how hard they work or how much they invent, these designers will not be revered as pioneers. They are blazing trails through a parking lot. Our pioneers are those who transcend interaction—designers whose creations anticipatenot obey.

The hero of tomorrow is not the next Steve Wozniak, but the next William Playfair. An artist who redefines how people learn. An artist who paints with magic ink. Software design consists of graphic design drawing pictures and industrial design allowing for mechanical manipulation.

Information software is for learning an internal model. Manipulation software is for creating an external model. Communication software is for communicating a shared model. Information software design is the design of context-sensitive information graphics. Information software is not a machine, but a medium for visual communication. Context can be inferred from the environment, which can include physical sensors, other information software, documents created with manipulation software, and data such as email which acts as a user profile.

Context can be inferred from a history of past environments and interactions. Last-value predictors provide a rudimentary approach. Learning predictors can infer patterns and make dynamic predictions.

Context can be inferred from user interaction, but only as a last resort. The best way to reduce or eliminate interaction is through information-rich graphic design that uses the environment and history. Remaining interaction can be reduced with graphical manipulation, relative navigation, and tight feedback loops. The information software revolution will require public recognition that information software is a medium of visual communication, designers with talent, skill, and tools, simple and general platforms, and an environment that encourages creativity and sharing.