Wednesday, November 04, 2009
Monday, October 12, 2009
Tuesday, July 21, 2009
50 Useful Google Apps for Writers
Writers, especially those who work from home or who juggle busy schedules around multiple assignments, have a lot to manage–note pads, sticky notes, brainstorming lists, correspondence with clients and editors, and even personal documents and materials that take up a lot of space and time. With its new applications and tools, Google continues to make it easier to manage all that. Below are some of our top picks for the most useful Google apps for writers.
Link is here!
Link is here!
Tuesday, July 14, 2009
A Summary of Principles for User-Interface Design.
1. The principle of user profiling
-- Know who your user is.
Before we can answer the question "How do we make our user-interfaces better", we must first answer the question: Better for whom? A design that is better for a technically skilled user might not be better for a non-technical businessman or an artist.
One way around this problem is to create user models. [TOG91] has an excellent chapter on brainstorming towards creating "profiles" of possible users. The result of this process is a detailed description of one or more "average" users, with specific details such as:
* What are the user's goals?
* What are the user's skills and experience?
* What are the user's needs?
Armed with this information, we can then proceed to answer the question: How do we leverage the user's strengths and create an interface that helps them achieve their goals?
In the case of a large general-purpose piece of software such as an operating system, there may be many different kinds of potential users. In this case it may be more useful to come up with a list of user dichotomies, such as "skilled vs. unskilled", "young vs. old", etc., or some other means of specifying a continuum or collection of user types.
Another way of answering this question is to talk to some real users. Direct contact between end-users and developers has often radically transformed the development process.
2. The principle of metaphor
-- Borrow behaviors from systems familiar to your users.
Frequently a complex software system can be understood more easily if the user interface is depicted in a way that resembles some commonplace system. The ubiquitous "Desktop metaphor" is an overused and trite example. Another is the tape deck metaphor seen on many audio and video player programs. In addition to the standard transport controls (play, rewind, etc.), the tape deck metaphor can be extended in ways that are quite natural, with functions such as time-counters and cueing buttons. This concept of "extendibility" is what distinguishes a powerful metaphor from a weak one.
There are several factors to consider when using a metaphor:
* Once a metaphor is chosen, it should be spread widely throughout the interface, rather than used once at a specific point. Even better would be to use the same metaphor spread over several applications (the tape transport controls described above is a good example.) Don't bother thinking up a metaphor which is only going to apply to a single button.
* There's no reason why an application cannot incorporate several different metaphors, as long as they don't clash. Music sequencers, for example, often incorporate both "tape transport" and "sheet music" metaphors.
* Metaphor isn't always necessary. In many cases the natural function of the software itself is easier to comprehend than any real-world analog of it. Don't strain a metaphor in adapting it to the program's real function. Nor should you strain the meaning of a particular program feature in order to adapt it to a metaphor.
* Incorporating a metaphor is not without certain risks. In particular, whenever physical objects are represented in a computer system, we inherit not only the beneficial functions of those objects but also the detrimental aspects.
* Be aware that some metaphors don't cross cultural boundaries well. For example, Americans would instantly recognize the common U.S. Mailbox (with a rounded top, a flat bottom, and a little red flag on the side), but there are no mailboxes of this style in Europe.
3. The principle of feature exposure
-- Let the user see clearly what functions are available
Software developers tend to have little difficulty keeping large, complex mental models in their heads. But not everyone prefers to "live in their heads" -- instead, they prefer to concentrate on analyzing the sensory details of the environment, rather than spending large amounts of time refining and perfecting abstract models. Both type of personality (labeled "Intuitive" and "Sensable" in the Myers-Briggs personality classification) can be equally intelligent, but focus on different aspects of life. It is to be noted that according to some psychological studies "Sensables" outnumber "Intuitives" in the general population by about three to one.
Intuitives prefer user interfaces that utilize the power of abstract models -- command lines, scripts, plug-ins, macros, etc. Sensables prefer user interfaces that utilize their perceptual abilities -- in other words, they like interfaces where the features are "up front" and "in their face". Toolbars and dialog boxes are an example of interfaces that are pleasing to this personality type.
This doesn't mean that you have to make everything a GUI. What it does mean, for both GUI and command line programs, is that the features of the program need to be easily exposed so that a quick visual scan can determine what the program actually does. In some cases, such as a toolbar, the program features are exposed by default. In other cases, such as a printer configuration dialog, the exposure of the underlying printer state (i.e. the buttons and controls which depict the conceptual printing model) are contained in a dialog box which is brought up by a user action (a feature which is itself exposed in a menu).
Of course, there may be cases where you don't wish to expose a feature right away, because you don't want to overwhelm the beginning user with too much detail. In this case, it is best to structure the application like the layers of an onion, where peeling away each layer of skin reveals a layer beneath. There are various levels of "hiding": Here's a partial list of them in order from most exposed to least exposed:
* Toolbar (completely exposed)
* Menu item (exposed by trivial user gesture)
* Submenu item (exposed by somewhat more involved user gesture)
* Dialog box (exposed by explicit user command)
* Secondary dialog box (invoked by button in first dialog box)
* "Advanced user mode" controls -- exposed when user selects "advanced" option
* Scripted functions
The above notwithstanding, in no case should the primary interface of the application be a reflection of the true complexity of the underlying implementation. Instead, both the interface and the implementation should strive to match a simplified conceptual model (in other words, the design) of what the application does. For example, when an error occurs, the explanation of the error should be phrased in a way that relates to the current user-centered activity, and not in terms of the low-level fault that caused there error.
4. The principle of coherence
-- The behavior of the program should be internally and externally consistent
There's been some argument over whether interfaces should strive to be "intuitive", or whether an intuitive interface is even possible. However, it is certainly arguable that an interface should be coherent -- in other words logical, consistent, and easily followed. ("Coherent" literally means "stick together", and that's exactly what the parts of an interface design should do.)
Internal consistency means that the program's behaviors make "sense" with respect to other parts of the program. For example, if one attribute of an object (e.g. color) is modifiable using a pop-up menu, then it is to be expected that other attributes of the object would also be editable in a similar fashion. One should strive towards the principle of "least surprise".
External consistency means that the program is consistent with the environment in which it runs. This includes consistency with both the operating system and the typical suite of applications that run within that operating system. One of the most widely recognized forms of external coherence is compliance with user-interface standards. There are many others, however, such as the use of standardized scripting languages, plug-in architectures or configuration methods.
5. The principle of state visualization
-- Changes in behavior should be reflected in the appearance of the program
Each change in the behavior of the program should be accompanied by a corresponding change in the appearance of the interface. One of the big criticisms of "modes" in interfaces is that many of the classic "bad example" programs have modes that are visually indistinguishable from one another.
Similarly, when a program changes its appearance, it should be in response to a behavior change; A program that changes its appearance for no apparent reason will quickly teach the user not to depend on appearances for clues as to the program's state.
One of the most important kinds of state is the current selection, in other words the object or set of objects that will be affected by the next command. It is important that this internal state be visualized in a way that is consistent, clear, and unambiguous. For example, one common mistake seen in a number of multi-document applications is to forget to "dim" the selection when the window goes out of focus. The result of this is that a user, looking at several windows at once, each with a similar-looking selection, may be confused as to exactly which selection will be affected when they hit the "delete" key. This is especially true if the user has been focusing on the selection highlight, and not on the window frame, and consequently has failed to notice which window is the active one. (Selection rules are one of those areas that are covered poorly by most UI style guidelines, which tend to concentrate on "widgets", although the Mac and Amiga guidelines each have a chapter on this topic.)
6. The principle of shortcuts
-- Provide both concrete and abstract ways of getting a task done
Once a user has become experienced with an application, she will start to build a mental model of that application. She will be able to predict with high accuracy what the results of any particular user gesture will be in any given context. At this point, the program's attempts to make things "easy" by breaking up complex actions into simple steps may seem cumbersome. Additionally, as this mental model grows, there will be less and less need to look at the "in your face" exposure of the application's feature set. Instead, pre-memorized "shortcuts" should be available to allow rapid access to more powerful functions.
There are various levels of shortcuts, each one more abstract than its predecessor. For example, in the emacs editor commands can be invoked directly by name, by menu bar, by a modified keystroke combination, or by a single keystroke. Each of these is more "accelerated" than its predecessor.
There can also be alternate methods of invoking commands that are designed to increase power rather than to accelerate speed. A "recordable macro" facility is one of these, as is a regular-expression search and replace. The important thing about these more powerful (and more abstract) methods is that they should not be the most exposed methods of accomplishing the task. This is why emacs has the non-regexp version of search assigned to the easy-to-remember "C-s" key.
7. The principle of focus
-- Some aspects of the UI attract attention more than others do
The human eye is a highly non-linear device. For example, it possesses edge-detection hardware, which is why we see Mach bands whenever two closely matched areas of color come into contact. It also has motion-detection hardware. As a consequence, our eyes are drawn to animated areas of the display more readily than static areas. Changes to these areas will be noticed readily.
The mouse cursor is probably the most intensely observed object on the screen -- it's not only a moving object, but mouse users quickly acquire the habit of tracking it with their eyes in order to navigate. This is why global state changes are often signaled by changes to the appearance of the cursor, such as the well-known "hourglass cursor". It's nearly impossible to miss.
The text cursor is another example of a highly eye-attractive object. Changing its appearance can signal a number of different and useful state changes.
8. The principle of grammar
-- A user interface is a kind of language -- know what the rules are
Many of the operations within a user interface require both a subject (an object to be operated upon), and a verb (an operation to perform on the object). This naturally suggests that actions in the user interface form a kind of grammar. The grammatical metaphor can be extended quite a bit, and there are elements of some programs that can be clearly identified as adverbs, adjectives and such.
The two most common grammars are known as "Action->Object" and "Object->Action". In Action->Object, the operation (or tool) is selected first. When a subsequent object is chosen, the tool immediately operates upon the object. The selection of the tool persists from one operation to the next, so that many objects can be operated on one by one without having to re-select the tool. Action->Object is also known as "modality", because the tool selection is a "mode" which changes the operation of the program. An example of this style is a paint program -- a tool such as a paintbrush or eraser is selected, which can then make many brush strokes before a new tool is selected.
In the Object->Action case, the object is selected first and persists from one operation to the next. Individual actions are then chosen which operate on the currently selected object or objects. This is the method seen in most word processors -- first a range of text is selected, and then a text style such as bold, italic, or a font change can be selected. Object->Action has been called "non-modal" because all behaviors that can be applied to the object are always available. One powerful type of Object->Action is called "direct manipulation", where the object itself is a kind of tool -- an example is dragging the object to a new position or resizing it.
Modality has been much criticized in user-interface literature because early programs were highly modal and had hideous interfaces. However, while non-modality is the clear winner in many situations, there are a large number of situations in life that are clearly modal. For example, in carpentry, its generally more efficient to hammer in a whole bunch of nails at once than to hammer in one nail, put down the hammer, pick up the measuring tape, mark the position of the next nail, pick up the drill, etc.
9. The principle of help
-- Understand the different kinds of help a user needs
In an essay in [LAUR91] it states that are five basic types of help, corresponding to the five basic questions that users ask:
* 1. Goal-oriented: "What kinds of things can I do with this program?"
* 2. Descriptive: "What is this? What does this do?"
* 3. Procedural: "How do I do this?"
* 4. Interpretive: "Why did this happen?"
* 5. Navigational: "Where am I?"
The essay goes on to describe in detail the different strategies for answering these questions, and shows how each of these questions requires a different sort of help interface in order for the user to be able to adequately phrase the question to the application.
For example, "about boxes" are one way of addressing the needs of question of type 1. Questions of type 2 can be answered with a standard "help browser", "tool tips" or other kinds of context-sensitive help. A help browser can also be useful in responding to questions of the third type, but these can sometimes be more efficiently addressed using "cue cards", interactive "guides", or "wizards" which guide the user through the process step-by-step. The fourth type has not been well addressed in current applications, although well-written error messages can help. The fifth type can be answered by proper overall interface design, or by creating an application "roadmap". None of the solutions listed in this paragraph are final or ideal; they are simply the ones in common use by many applications today.
10. The principle of safety
-- Let the user develop confidence by providing a safety net
Ted Nelson once said "Using DOS is like juggling with straight razors. Using a Mac is like shaving with a bowling pin."
Each human mind has an "envelope of risk", that is to say a minimum and maximum range of risk-levels which they find comfortable. A person who finds herself in a situation that is too risky for her comfort will generally take steps to reduce that risk. Conversely, when a person's life becomes too safe -- in other words, when the risk level drops below the minimum threshold of the risk envelope -- she will often engage in actions that increase their level of risk.
This comfort envelope varies for different people and in different situations. In the case of computer interfaces, a level of risk that is comfortable for a novice user might make a "power-user" feel uncomfortably swaddled in safety.
It's important for new users that they feel safe. They don't trust themselves or their skills to do the right thing. Many novice users think poorly not only of their technical skills, but of their intellectual capabilities in general (witness the popularity of the "...for Dummies" series of tutorial books.) In many cases these fears are groundless, but they need to be addressed. Novice users need to be assured that they will be protected from their own lack of skill. A program with no safety net will make this type of user feel uncomfortable or frustrated to the point that they may cease using the program. The "Are you sure?" dialog box and multi-level undo features are vital for this type of user.
At the same time, an expert user must be able to use the program as a virtuoso. She must not be hampered by guard rails or helmet laws. However, expert users are also smart enough to turn off the safety checks -- if the application allows it. This is why "safety level" is one of the more important application configuration options.
Finally, it should be noted that many things in life are not meant to be easy. Physical exercise is one -- "no pain, no gain". A concert performance in Carnegie Hall, a marathon, or the Guinness World Record would be far less impressive if anybody could do it. This is especially pertinent in the design of computer game interfaces, which operate under somewhat different principles than those listed here (although many of the principles in fact do apply).
11. The principle of context
-- Limit user activity to one well-defined context unless there's a good reason not to
Each user action takes place within a given context -- the current document, the current selection, the current dialog box. A set of operations that is valid in one context may not be valid in another. Even within a single document, there may be multiple levels -- for example, in a structured drawing application, selecting a text object (which can be moved or resized) is generally considered a different state from selecting an individual character within that text object.
It's usually a good idea to avoid mixing these levels. For example, imagine an application that allows users to select a range of text characters within a document, and also allows them to select one or more whole documents (the latter being a distinct concept from selecting all of the characters in a document). In such a case, it's probably best if the program disallows selecting both characters and documents in the same selection. One unobtrusive way to do this is to "dim" the selection that is not applicable in the current context. In the example above, if the user had a range of text selected, and then selected a document, the range of selected characters could become dim, indicating that the selection was not currently pertinent. The exact solution chosen will of course depend on the nature of the application and the relationship between the contexts.
Another thing to keep in mind is the relationship between contexts. For example, it is often the case that the user is working in a particular task-space, when suddenly a dialog box will pop up asking the user for confirmation of an action. This sudden shift of context may leave the user wondering how the new context relates to the old. This confusion is exacerbated by the terseness of writing style that is common amongst application writers. Rather than the "Are you sure?" confirmation mentioned earlier, something like "There are two documents unsaved. Do you want to quit anyway?" would help to keep the user anchored in their current context.
12. The principle of aesthetics
-- Create a program of beauty
It's not necessary that each program be a visual work of art. But it's important that it not be ugly. There are a number of simple principles of graphical design that can easily be learned, the most basic of which was coined by artist and science fiction writer William Rotsler: "Never do anything that looks to someone else like a mistake." The specific example Rotsler used was a painting of a Conan-esque barbarian warrior swinging a mighty broadsword. In this picture, the tip of the broadsword was just off the edge of the picture. "What that looks like", said Rotsler, "is a picture that's been badly cropped. They should have had the tip of the sword either clearly within the frame or clearly out of it."
An interface example can be seen in the placement of buttons -- imagine five buttons, each with five different labels that are almost the same size. Because the buttons are packed using an automated-layout algorithm, each button is almost but not exactly the same size. As a result, though the author has placed much care into his layout, it looks carelessly done. A solution would be to have the packing algorithm know that buttons that are almost the same size look better if they are exactly the same size -- in other words, to encode some of the rules of graphical design into the layout algorithm. Similar arguments hold for manual widget layout.
Another area of aesthetics to consider is the temporal dimension. Users don't like using programs that feel sluggish or slow. There are many tricks that can be used to make a slow program "feel" snappy, such as the use of off-screen bitmaps for rendering, which can then be blitted forward in a single operation. (A pet peeve of this particular author is buttons that flicker when the button is being activated or the window is being resized. Multiply redundant refreshing of buttons when changing state is one common cause of this.)
13. The principle of user testing
-- Recruit help in spotting the inevitable defects in your design
In many cases a good software designer can spot fundamental defects in a user interface. However, there are many kinds of defects which are not so easy to spot, and in fact an experienced software designer is often less capable of spotting them than the average person. In other cases, a bug can only be detected while watching someone else use the program.
User-interface testing, that is, the testing of user-interfaces using actual end-users, has been shown to be an extraordinarily effective technique for discovering design defects. However, there are specific techniques that can be used to maximize the effectiveness of end-user testing. These are outlined in both [TOG91] and [LAUR91] and can be summarized in the following steps:
* Set up the observation. Design realistic tasks for the users, and then recruit end-users that have the same experience level as users of your product (Avoid recruiting users who are familiar with your product however).
* Describe to the user the purpose of the observation. Let them know that you're testing the product, not them, and that they can quit at any time. Make sure that they understand if anything bad happens, it's not their fault, and that it's helping you to find problems.
* Talk about and demonstrate the equipment in the room.
* Explain how to "think aloud". Ask them to verbalize what they are thinking about as they use the product, and let them know you'll remind them to do so if they forget.
* Explain that you will not provide help.
* Describe the tasks and introduce the product.
* Ask if there are any questions before you start; then begin the observation.
* Conclude the observation. Tell them what you found out and answer any of their questions.
* Use the results.
User testing can occur at any time during the project, however, it's often more efficient to build a mock-up or prototype of the application and test that before building the real program. It's much easier to deal with a design defect before it's implemented than after. Tognazzini suggests that you need no more than three people per design iteration -- any more than that and you are just confirming problems already found.
14. The principle of humility
-- Listen to what ordinary people have to say
Some of the most valuable insights can be gained by simply watching other people attempt to use your program. Others can come from listening to their opinions about the product. Of course, you don't have to do exactly everything they say. It's important to realize that each of you, user and developer, has only part of the picture. The ideal is to take a lot of user opinions, plus your insights as a developer and reduce them into an elegant and seamless whole -- a design which, though it may not satisfy everyone, will satisfy the greatest needs of the greatest number of people.
One must be true to one's vision. A product built entirely from customer feedback is doomed to mediocrity, because what users want most are the features that they cannot anticipate.
But a single designer's intuition about what is good and bad in an application is insufficient. Program creators are a small, and not terribly representative, subset of the general computing population.
Some things designers should keep in mind about their users:
* Most people have a biased idea as to the what the "average" person is like. This is because most of our interpersonal relationships are in some way self-selected. It's a rare person whose daily life brings them into contact with other people from a full range of personality types and backgrounds. As a result, we tend to think that others think "mostly like we do." Designers are no exception.
* Most people have some sort of core competancy, and can be expected to perform well within that domain.
* The skill of using a computer (also known as "computer literacy") is actually much harder than it appears.
* The lack of "computer literacy" is not an indication of a lack of basic intelligence. While native intelligence does contribute to one's ability to use a computer effectively, there are other factors which seem to be just as significant, such as a love of exploring complex systems, and an attitude of playful experimentation. Much of the fluency with computer interfaces derives from play -- and those who have dedicated themselves to "serious" tasks such as running a business, curing disease, or helping victims of tragedy may lack the time or patience to be able to devote effort to it.
* A high proportion of programmers are introverts, compared to the general population. This doesn't mean that they don't like people, but rather that there are specific social situations that make them uncomfortable. Many of them lack social skills, and retreat into the world of logic and programming as an escape; As a result, they are not experienced people-watchers.
The best way to avoid misconceptions about users is to spend some time with them, especially while they are actually using a computer. Do this long enough, and eventually you will get a "feel" for how the average non-technical person thinks. This will increase your ability to spot defects, although it will never make it 100%, and will never be a substitute for user-testing.
Bibliography
[TOG91] Tog On Interface, Bruce Tognazzini, Addison-Wesley, 1991, ISBN 0-201-60842-1
[LAUR91] The Art of Human Computer Interface Design, Brenda Laurel, Addison-Wesley, 1991, ISBN 0-201-51797-3
The Psychology of Everyday Things, Don Norman, Harper-Collins 1988, ISBN 0-465-06709-3
The Macintosh Human Interface Guidelines, Apple Computer Staff, Addison-Wesley 1993, ISBN 0-201-62216-5
The Amiga User Interface Style Guide, Commodore-Amiga, Addison-Wesley 1991, ISBN 0-201-57757-7
Credits and Change History
August 14, 1998: Initial public release.
August 19, 1998: Applied grammatical fixes sent in by Kuraiken and Mark Ellis. Made various additions attempting to fix deficiencies pointed out by James Cook (risks of metaphors), Richard Kail (cross-cultural metaphors) and Stephan Bethke (terse and uninformative dialog boxes).
sursa : http://www.sylvantech.com/~talin/projects/ui_design.html
-- Know who your user is.
Before we can answer the question "How do we make our user-interfaces better", we must first answer the question: Better for whom? A design that is better for a technically skilled user might not be better for a non-technical businessman or an artist.
One way around this problem is to create user models. [TOG91] has an excellent chapter on brainstorming towards creating "profiles" of possible users. The result of this process is a detailed description of one or more "average" users, with specific details such as:
* What are the user's goals?
* What are the user's skills and experience?
* What are the user's needs?
Armed with this information, we can then proceed to answer the question: How do we leverage the user's strengths and create an interface that helps them achieve their goals?
In the case of a large general-purpose piece of software such as an operating system, there may be many different kinds of potential users. In this case it may be more useful to come up with a list of user dichotomies, such as "skilled vs. unskilled", "young vs. old", etc., or some other means of specifying a continuum or collection of user types.
Another way of answering this question is to talk to some real users. Direct contact between end-users and developers has often radically transformed the development process.
2. The principle of metaphor
-- Borrow behaviors from systems familiar to your users.
Frequently a complex software system can be understood more easily if the user interface is depicted in a way that resembles some commonplace system. The ubiquitous "Desktop metaphor" is an overused and trite example. Another is the tape deck metaphor seen on many audio and video player programs. In addition to the standard transport controls (play, rewind, etc.), the tape deck metaphor can be extended in ways that are quite natural, with functions such as time-counters and cueing buttons. This concept of "extendibility" is what distinguishes a powerful metaphor from a weak one.
There are several factors to consider when using a metaphor:
* Once a metaphor is chosen, it should be spread widely throughout the interface, rather than used once at a specific point. Even better would be to use the same metaphor spread over several applications (the tape transport controls described above is a good example.) Don't bother thinking up a metaphor which is only going to apply to a single button.
* There's no reason why an application cannot incorporate several different metaphors, as long as they don't clash. Music sequencers, for example, often incorporate both "tape transport" and "sheet music" metaphors.
* Metaphor isn't always necessary. In many cases the natural function of the software itself is easier to comprehend than any real-world analog of it. Don't strain a metaphor in adapting it to the program's real function. Nor should you strain the meaning of a particular program feature in order to adapt it to a metaphor.
* Incorporating a metaphor is not without certain risks. In particular, whenever physical objects are represented in a computer system, we inherit not only the beneficial functions of those objects but also the detrimental aspects.
* Be aware that some metaphors don't cross cultural boundaries well. For example, Americans would instantly recognize the common U.S. Mailbox (with a rounded top, a flat bottom, and a little red flag on the side), but there are no mailboxes of this style in Europe.
3. The principle of feature exposure
-- Let the user see clearly what functions are available
Software developers tend to have little difficulty keeping large, complex mental models in their heads. But not everyone prefers to "live in their heads" -- instead, they prefer to concentrate on analyzing the sensory details of the environment, rather than spending large amounts of time refining and perfecting abstract models. Both type of personality (labeled "Intuitive" and "Sensable" in the Myers-Briggs personality classification) can be equally intelligent, but focus on different aspects of life. It is to be noted that according to some psychological studies "Sensables" outnumber "Intuitives" in the general population by about three to one.
Intuitives prefer user interfaces that utilize the power of abstract models -- command lines, scripts, plug-ins, macros, etc. Sensables prefer user interfaces that utilize their perceptual abilities -- in other words, they like interfaces where the features are "up front" and "in their face". Toolbars and dialog boxes are an example of interfaces that are pleasing to this personality type.
This doesn't mean that you have to make everything a GUI. What it does mean, for both GUI and command line programs, is that the features of the program need to be easily exposed so that a quick visual scan can determine what the program actually does. In some cases, such as a toolbar, the program features are exposed by default. In other cases, such as a printer configuration dialog, the exposure of the underlying printer state (i.e. the buttons and controls which depict the conceptual printing model) are contained in a dialog box which is brought up by a user action (a feature which is itself exposed in a menu).
Of course, there may be cases where you don't wish to expose a feature right away, because you don't want to overwhelm the beginning user with too much detail. In this case, it is best to structure the application like the layers of an onion, where peeling away each layer of skin reveals a layer beneath. There are various levels of "hiding": Here's a partial list of them in order from most exposed to least exposed:
* Toolbar (completely exposed)
* Menu item (exposed by trivial user gesture)
* Submenu item (exposed by somewhat more involved user gesture)
* Dialog box (exposed by explicit user command)
* Secondary dialog box (invoked by button in first dialog box)
* "Advanced user mode" controls -- exposed when user selects "advanced" option
* Scripted functions
The above notwithstanding, in no case should the primary interface of the application be a reflection of the true complexity of the underlying implementation. Instead, both the interface and the implementation should strive to match a simplified conceptual model (in other words, the design) of what the application does. For example, when an error occurs, the explanation of the error should be phrased in a way that relates to the current user-centered activity, and not in terms of the low-level fault that caused there error.
4. The principle of coherence
-- The behavior of the program should be internally and externally consistent
There's been some argument over whether interfaces should strive to be "intuitive", or whether an intuitive interface is even possible. However, it is certainly arguable that an interface should be coherent -- in other words logical, consistent, and easily followed. ("Coherent" literally means "stick together", and that's exactly what the parts of an interface design should do.)
Internal consistency means that the program's behaviors make "sense" with respect to other parts of the program. For example, if one attribute of an object (e.g. color) is modifiable using a pop-up menu, then it is to be expected that other attributes of the object would also be editable in a similar fashion. One should strive towards the principle of "least surprise".
External consistency means that the program is consistent with the environment in which it runs. This includes consistency with both the operating system and the typical suite of applications that run within that operating system. One of the most widely recognized forms of external coherence is compliance with user-interface standards. There are many others, however, such as the use of standardized scripting languages, plug-in architectures or configuration methods.
5. The principle of state visualization
-- Changes in behavior should be reflected in the appearance of the program
Each change in the behavior of the program should be accompanied by a corresponding change in the appearance of the interface. One of the big criticisms of "modes" in interfaces is that many of the classic "bad example" programs have modes that are visually indistinguishable from one another.
Similarly, when a program changes its appearance, it should be in response to a behavior change; A program that changes its appearance for no apparent reason will quickly teach the user not to depend on appearances for clues as to the program's state.
One of the most important kinds of state is the current selection, in other words the object or set of objects that will be affected by the next command. It is important that this internal state be visualized in a way that is consistent, clear, and unambiguous. For example, one common mistake seen in a number of multi-document applications is to forget to "dim" the selection when the window goes out of focus. The result of this is that a user, looking at several windows at once, each with a similar-looking selection, may be confused as to exactly which selection will be affected when they hit the "delete" key. This is especially true if the user has been focusing on the selection highlight, and not on the window frame, and consequently has failed to notice which window is the active one. (Selection rules are one of those areas that are covered poorly by most UI style guidelines, which tend to concentrate on "widgets", although the Mac and Amiga guidelines each have a chapter on this topic.)
6. The principle of shortcuts
-- Provide both concrete and abstract ways of getting a task done
Once a user has become experienced with an application, she will start to build a mental model of that application. She will be able to predict with high accuracy what the results of any particular user gesture will be in any given context. At this point, the program's attempts to make things "easy" by breaking up complex actions into simple steps may seem cumbersome. Additionally, as this mental model grows, there will be less and less need to look at the "in your face" exposure of the application's feature set. Instead, pre-memorized "shortcuts" should be available to allow rapid access to more powerful functions.
There are various levels of shortcuts, each one more abstract than its predecessor. For example, in the emacs editor commands can be invoked directly by name, by menu bar, by a modified keystroke combination, or by a single keystroke. Each of these is more "accelerated" than its predecessor.
There can also be alternate methods of invoking commands that are designed to increase power rather than to accelerate speed. A "recordable macro" facility is one of these, as is a regular-expression search and replace. The important thing about these more powerful (and more abstract) methods is that they should not be the most exposed methods of accomplishing the task. This is why emacs has the non-regexp version of search assigned to the easy-to-remember "C-s" key.
7. The principle of focus
-- Some aspects of the UI attract attention more than others do
The human eye is a highly non-linear device. For example, it possesses edge-detection hardware, which is why we see Mach bands whenever two closely matched areas of color come into contact. It also has motion-detection hardware. As a consequence, our eyes are drawn to animated areas of the display more readily than static areas. Changes to these areas will be noticed readily.
The mouse cursor is probably the most intensely observed object on the screen -- it's not only a moving object, but mouse users quickly acquire the habit of tracking it with their eyes in order to navigate. This is why global state changes are often signaled by changes to the appearance of the cursor, such as the well-known "hourglass cursor". It's nearly impossible to miss.
The text cursor is another example of a highly eye-attractive object. Changing its appearance can signal a number of different and useful state changes.
8. The principle of grammar
-- A user interface is a kind of language -- know what the rules are
Many of the operations within a user interface require both a subject (an object to be operated upon), and a verb (an operation to perform on the object). This naturally suggests that actions in the user interface form a kind of grammar. The grammatical metaphor can be extended quite a bit, and there are elements of some programs that can be clearly identified as adverbs, adjectives and such.
The two most common grammars are known as "Action->Object" and "Object->Action". In Action->Object, the operation (or tool) is selected first. When a subsequent object is chosen, the tool immediately operates upon the object. The selection of the tool persists from one operation to the next, so that many objects can be operated on one by one without having to re-select the tool. Action->Object is also known as "modality", because the tool selection is a "mode" which changes the operation of the program. An example of this style is a paint program -- a tool such as a paintbrush or eraser is selected, which can then make many brush strokes before a new tool is selected.
In the Object->Action case, the object is selected first and persists from one operation to the next. Individual actions are then chosen which operate on the currently selected object or objects. This is the method seen in most word processors -- first a range of text is selected, and then a text style such as bold, italic, or a font change can be selected. Object->Action has been called "non-modal" because all behaviors that can be applied to the object are always available. One powerful type of Object->Action is called "direct manipulation", where the object itself is a kind of tool -- an example is dragging the object to a new position or resizing it.
Modality has been much criticized in user-interface literature because early programs were highly modal and had hideous interfaces. However, while non-modality is the clear winner in many situations, there are a large number of situations in life that are clearly modal. For example, in carpentry, its generally more efficient to hammer in a whole bunch of nails at once than to hammer in one nail, put down the hammer, pick up the measuring tape, mark the position of the next nail, pick up the drill, etc.
9. The principle of help
-- Understand the different kinds of help a user needs
In an essay in [LAUR91] it states that are five basic types of help, corresponding to the five basic questions that users ask:
* 1. Goal-oriented: "What kinds of things can I do with this program?"
* 2. Descriptive: "What is this? What does this do?"
* 3. Procedural: "How do I do this?"
* 4. Interpretive: "Why did this happen?"
* 5. Navigational: "Where am I?"
The essay goes on to describe in detail the different strategies for answering these questions, and shows how each of these questions requires a different sort of help interface in order for the user to be able to adequately phrase the question to the application.
For example, "about boxes" are one way of addressing the needs of question of type 1. Questions of type 2 can be answered with a standard "help browser", "tool tips" or other kinds of context-sensitive help. A help browser can also be useful in responding to questions of the third type, but these can sometimes be more efficiently addressed using "cue cards", interactive "guides", or "wizards" which guide the user through the process step-by-step. The fourth type has not been well addressed in current applications, although well-written error messages can help. The fifth type can be answered by proper overall interface design, or by creating an application "roadmap". None of the solutions listed in this paragraph are final or ideal; they are simply the ones in common use by many applications today.
10. The principle of safety
-- Let the user develop confidence by providing a safety net
Ted Nelson once said "Using DOS is like juggling with straight razors. Using a Mac is like shaving with a bowling pin."
Each human mind has an "envelope of risk", that is to say a minimum and maximum range of risk-levels which they find comfortable. A person who finds herself in a situation that is too risky for her comfort will generally take steps to reduce that risk. Conversely, when a person's life becomes too safe -- in other words, when the risk level drops below the minimum threshold of the risk envelope -- she will often engage in actions that increase their level of risk.
This comfort envelope varies for different people and in different situations. In the case of computer interfaces, a level of risk that is comfortable for a novice user might make a "power-user" feel uncomfortably swaddled in safety.
It's important for new users that they feel safe. They don't trust themselves or their skills to do the right thing. Many novice users think poorly not only of their technical skills, but of their intellectual capabilities in general (witness the popularity of the "...for Dummies" series of tutorial books.) In many cases these fears are groundless, but they need to be addressed. Novice users need to be assured that they will be protected from their own lack of skill. A program with no safety net will make this type of user feel uncomfortable or frustrated to the point that they may cease using the program. The "Are you sure?" dialog box and multi-level undo features are vital for this type of user.
At the same time, an expert user must be able to use the program as a virtuoso. She must not be hampered by guard rails or helmet laws. However, expert users are also smart enough to turn off the safety checks -- if the application allows it. This is why "safety level" is one of the more important application configuration options.
Finally, it should be noted that many things in life are not meant to be easy. Physical exercise is one -- "no pain, no gain". A concert performance in Carnegie Hall, a marathon, or the Guinness World Record would be far less impressive if anybody could do it. This is especially pertinent in the design of computer game interfaces, which operate under somewhat different principles than those listed here (although many of the principles in fact do apply).
11. The principle of context
-- Limit user activity to one well-defined context unless there's a good reason not to
Each user action takes place within a given context -- the current document, the current selection, the current dialog box. A set of operations that is valid in one context may not be valid in another. Even within a single document, there may be multiple levels -- for example, in a structured drawing application, selecting a text object (which can be moved or resized) is generally considered a different state from selecting an individual character within that text object.
It's usually a good idea to avoid mixing these levels. For example, imagine an application that allows users to select a range of text characters within a document, and also allows them to select one or more whole documents (the latter being a distinct concept from selecting all of the characters in a document). In such a case, it's probably best if the program disallows selecting both characters and documents in the same selection. One unobtrusive way to do this is to "dim" the selection that is not applicable in the current context. In the example above, if the user had a range of text selected, and then selected a document, the range of selected characters could become dim, indicating that the selection was not currently pertinent. The exact solution chosen will of course depend on the nature of the application and the relationship between the contexts.
Another thing to keep in mind is the relationship between contexts. For example, it is often the case that the user is working in a particular task-space, when suddenly a dialog box will pop up asking the user for confirmation of an action. This sudden shift of context may leave the user wondering how the new context relates to the old. This confusion is exacerbated by the terseness of writing style that is common amongst application writers. Rather than the "Are you sure?" confirmation mentioned earlier, something like "There are two documents unsaved. Do you want to quit anyway?" would help to keep the user anchored in their current context.
12. The principle of aesthetics
-- Create a program of beauty
It's not necessary that each program be a visual work of art. But it's important that it not be ugly. There are a number of simple principles of graphical design that can easily be learned, the most basic of which was coined by artist and science fiction writer William Rotsler: "Never do anything that looks to someone else like a mistake." The specific example Rotsler used was a painting of a Conan-esque barbarian warrior swinging a mighty broadsword. In this picture, the tip of the broadsword was just off the edge of the picture. "What that looks like", said Rotsler, "is a picture that's been badly cropped. They should have had the tip of the sword either clearly within the frame or clearly out of it."
An interface example can be seen in the placement of buttons -- imagine five buttons, each with five different labels that are almost the same size. Because the buttons are packed using an automated-layout algorithm, each button is almost but not exactly the same size. As a result, though the author has placed much care into his layout, it looks carelessly done. A solution would be to have the packing algorithm know that buttons that are almost the same size look better if they are exactly the same size -- in other words, to encode some of the rules of graphical design into the layout algorithm. Similar arguments hold for manual widget layout.
Another area of aesthetics to consider is the temporal dimension. Users don't like using programs that feel sluggish or slow. There are many tricks that can be used to make a slow program "feel" snappy, such as the use of off-screen bitmaps for rendering, which can then be blitted forward in a single operation. (A pet peeve of this particular author is buttons that flicker when the button is being activated or the window is being resized. Multiply redundant refreshing of buttons when changing state is one common cause of this.)
13. The principle of user testing
-- Recruit help in spotting the inevitable defects in your design
In many cases a good software designer can spot fundamental defects in a user interface. However, there are many kinds of defects which are not so easy to spot, and in fact an experienced software designer is often less capable of spotting them than the average person. In other cases, a bug can only be detected while watching someone else use the program.
User-interface testing, that is, the testing of user-interfaces using actual end-users, has been shown to be an extraordinarily effective technique for discovering design defects. However, there are specific techniques that can be used to maximize the effectiveness of end-user testing. These are outlined in both [TOG91] and [LAUR91] and can be summarized in the following steps:
* Set up the observation. Design realistic tasks for the users, and then recruit end-users that have the same experience level as users of your product (Avoid recruiting users who are familiar with your product however).
* Describe to the user the purpose of the observation. Let them know that you're testing the product, not them, and that they can quit at any time. Make sure that they understand if anything bad happens, it's not their fault, and that it's helping you to find problems.
* Talk about and demonstrate the equipment in the room.
* Explain how to "think aloud". Ask them to verbalize what they are thinking about as they use the product, and let them know you'll remind them to do so if they forget.
* Explain that you will not provide help.
* Describe the tasks and introduce the product.
* Ask if there are any questions before you start; then begin the observation.
* Conclude the observation. Tell them what you found out and answer any of their questions.
* Use the results.
User testing can occur at any time during the project, however, it's often more efficient to build a mock-up or prototype of the application and test that before building the real program. It's much easier to deal with a design defect before it's implemented than after. Tognazzini suggests that you need no more than three people per design iteration -- any more than that and you are just confirming problems already found.
14. The principle of humility
-- Listen to what ordinary people have to say
Some of the most valuable insights can be gained by simply watching other people attempt to use your program. Others can come from listening to their opinions about the product. Of course, you don't have to do exactly everything they say. It's important to realize that each of you, user and developer, has only part of the picture. The ideal is to take a lot of user opinions, plus your insights as a developer and reduce them into an elegant and seamless whole -- a design which, though it may not satisfy everyone, will satisfy the greatest needs of the greatest number of people.
One must be true to one's vision. A product built entirely from customer feedback is doomed to mediocrity, because what users want most are the features that they cannot anticipate.
But a single designer's intuition about what is good and bad in an application is insufficient. Program creators are a small, and not terribly representative, subset of the general computing population.
Some things designers should keep in mind about their users:
* Most people have a biased idea as to the what the "average" person is like. This is because most of our interpersonal relationships are in some way self-selected. It's a rare person whose daily life brings them into contact with other people from a full range of personality types and backgrounds. As a result, we tend to think that others think "mostly like we do." Designers are no exception.
* Most people have some sort of core competancy, and can be expected to perform well within that domain.
* The skill of using a computer (also known as "computer literacy") is actually much harder than it appears.
* The lack of "computer literacy" is not an indication of a lack of basic intelligence. While native intelligence does contribute to one's ability to use a computer effectively, there are other factors which seem to be just as significant, such as a love of exploring complex systems, and an attitude of playful experimentation. Much of the fluency with computer interfaces derives from play -- and those who have dedicated themselves to "serious" tasks such as running a business, curing disease, or helping victims of tragedy may lack the time or patience to be able to devote effort to it.
* A high proportion of programmers are introverts, compared to the general population. This doesn't mean that they don't like people, but rather that there are specific social situations that make them uncomfortable. Many of them lack social skills, and retreat into the world of logic and programming as an escape; As a result, they are not experienced people-watchers.
The best way to avoid misconceptions about users is to spend some time with them, especially while they are actually using a computer. Do this long enough, and eventually you will get a "feel" for how the average non-technical person thinks. This will increase your ability to spot defects, although it will never make it 100%, and will never be a substitute for user-testing.
Bibliography
[TOG91] Tog On Interface, Bruce Tognazzini, Addison-Wesley, 1991, ISBN 0-201-60842-1
[LAUR91] The Art of Human Computer Interface Design, Brenda Laurel, Addison-Wesley, 1991, ISBN 0-201-51797-3
The Psychology of Everyday Things, Don Norman, Harper-Collins 1988, ISBN 0-465-06709-3
The Macintosh Human Interface Guidelines, Apple Computer Staff, Addison-Wesley 1993, ISBN 0-201-62216-5
The Amiga User Interface Style Guide, Commodore-Amiga, Addison-Wesley 1991, ISBN 0-201-57757-7
Credits and Change History
August 14, 1998: Initial public release.
August 19, 1998: Applied grammatical fixes sent in by Kuraiken and Mark Ellis. Made various additions attempting to fix deficiencies pointed out by James Cook (risks of metaphors), Richard Kail (cross-cultural metaphors) and Stephan Bethke (terse and uninformative dialog boxes).
sursa : http://www.sylvantech.com/~talin/projects/ui_design.html
Tuesday, April 21, 2009
Cum formatam un usb driver si-l transformam in NTFS
Start/settings/Control Panel/System/Hardware/Device Manager/Disk drives/USB Device/Properties/Policies/bifati Optimize for performance... (ca sa se activeze formatarea in NTFS) si click pe OK. inchideti ferestrele ramase. click pe my computer / pe removable disk click dreapta/ Format ... si o sa vedeti FAT32 si NTFS.
Friday, December 19, 2008
Top Tips to Extend Your Laptop Battery Life
by Erik Rhey
source http://www.pcmag.com/
You seasoned techies are no doubt thinking, "Another article on how to get more life from your laptop battery. Big deal. I already know how to do that." Well, Mr. or Ms. Techie, I scoff at your hubris. There's still plenty to learn when it comes to getting more juice from a charge and extending your battery's overall life.
So, yes, there are tips that most of us know:
1. Dim your screen.
2. Minimize background processes.
3. Don't use the CD/DVD drive.
4. Disable your wireless antenna when not in use.
But there's still a lot you may not know about battery technology and the things that both help and hinder your laptop's juicebox.
Getting More Minutes per Charge
You can fiddle with background processes and other software settings all you want, but your hardware is the biggest factor in battery life, according to PC Mag's lead analyst for laptops, Cisco Cheng. In fact, software such as power-management utilities can help minimize the impact internal components have on battery longevity. Knowing this can affect your buying decision if you're looking for a new laptop (see the "Picking a Laptop for Maximum Battery Life" section below) or help you get the most out of the trusty laptop you've got. Here are a few ways to optimize hardware for maximum battery output.
1. Turn off ports. Disabling unused ports and components, such as VGA, Ethernet, PCMCIA, USB, and yes, your wireless, too. You can do this through the Device Manager or by configuring a separate hardware profile (see next step).
2. Create Power-Saving Hardware Profiles. Configure your laptop for the various scenarios in which you use it (on a plane, at the coffee shop, at the office, and so on). You can do this through the Hardware Profiles menu by right-clicking on My Computer and selecting Preferences or by using a freeware utility such as SparkleXP (for Windows XP users).
3. Configure your display to turn off when not in use. This is different from just using a screensaver, because in many cases a screensaver still requires the display's backlight to be on. You can set the interval to turn the display off in Windows' Power Options—found in the Control Panel.
Extending the Overall Life
The easiest way to give your battery an early death is to damage it. And the two most common causes of damage are from overheating and overloading. Here's how you prevent overheating:
1. Use a cooling pad when using a notebook computer on your lap.
2. Avoid propping your laptop on a pillow, blanket, or other soft surface that can heat up.
3. Clean your desk. It sounds strange, but if you have a dusty, dirty desk, that dust will get into the vents and clog the cooling fan. Once the dust is inside your laptop, it is much harder to remove. You can try blasting it out with canned air, but you run the risk of damaging internal components. You can also remove the vent and clean out the grit, but remember that taking apart your laptop can void the warranty. So clean your desk at least once a week, if not daily.
4. Never store your laptop in a place where the air temperature exceeds 80 degrees Fahrenheit, such as a hot car or an outdoor patio.
5. Consider taking your battery out when using your laptop plugged into AC power. Just make sure to keep the contacts clean. If you need to clean them, use rubbing alcohol.
6. For lithium ion batteries, you do not need to discharge them fully and recharge constantly. Since they don't have the same "memory" as older nickel-metal hydride batteries, it is actually better to discharge a lithium ion only partially before recharging. You need to do a full discharge only about every 30 charges.
Overloading a battery occurs when you use an AC adapter that has a higher wattage than that specified on the laptop (and battery), or if the circuitry of the laptop consistently overcharges the battery. If you're using a replacement or spare adapter, make sure the wattage matches your laptop's within the specified voltage range. In the worst-case scenario, overloading can also damage your motherboard.
Picking a Laptop for Maximum Battery Life
If you're in the market for a new laptop, there are features and components you should consider to get the most mileage from the system's battery.
1. An ultra-low-voltage processor, such as the Intel Penryn or one from VIA's line of ULV processors.
2. A solid-state storage drive, which requires less power and, since there are no spinning parts, will suffer less wear and tear than a traditional hard drive.
3. An LED display. Although pricey, LEDs use much less power than LCD.
4. A smaller screen. A smaller screen means a smaller backlight, which will also save on battery drain.
According to Andrew Bradner, product line manager for APC, all lithium ion batteries are not created equal. The proof is in the pudding, or in this case the chemistry. Unfortunately, it is almost impossible to discern if the battery you're buying was manufactured in a top-notch facility using high-quality materials. And making that call is not as easy as assuming your laptop manufacturer's battery will be of better quality than a battery from a third-party vendor. But you can stick to a couple of key guidelines.
1. Don't skimp on your battery. If you choose the lowest-cost battery you'll probably get a battery that degrades quickly, and you'll end up buying a replacement too soon anyway. So spend the money now to save expense and frustration down the road.
2. Don't buy an expired battery. A good indicator of a battery's performance is how far into its product life it is, whether it's used or new. If possible, look at the bottom of the battery and find the manufacture date.
source http://www.pcmag.com/
You seasoned techies are no doubt thinking, "Another article on how to get more life from your laptop battery. Big deal. I already know how to do that." Well, Mr. or Ms. Techie, I scoff at your hubris. There's still plenty to learn when it comes to getting more juice from a charge and extending your battery's overall life.
So, yes, there are tips that most of us know:
1. Dim your screen.
2. Minimize background processes.
3. Don't use the CD/DVD drive.
4. Disable your wireless antenna when not in use.
But there's still a lot you may not know about battery technology and the things that both help and hinder your laptop's juicebox.
Getting More Minutes per Charge
You can fiddle with background processes and other software settings all you want, but your hardware is the biggest factor in battery life, according to PC Mag's lead analyst for laptops, Cisco Cheng. In fact, software such as power-management utilities can help minimize the impact internal components have on battery longevity. Knowing this can affect your buying decision if you're looking for a new laptop (see the "Picking a Laptop for Maximum Battery Life" section below) or help you get the most out of the trusty laptop you've got. Here are a few ways to optimize hardware for maximum battery output.
1. Turn off ports. Disabling unused ports and components, such as VGA, Ethernet, PCMCIA, USB, and yes, your wireless, too. You can do this through the Device Manager or by configuring a separate hardware profile (see next step).
2. Create Power-Saving Hardware Profiles. Configure your laptop for the various scenarios in which you use it (on a plane, at the coffee shop, at the office, and so on). You can do this through the Hardware Profiles menu by right-clicking on My Computer and selecting Preferences or by using a freeware utility such as SparkleXP (for Windows XP users).
3. Configure your display to turn off when not in use. This is different from just using a screensaver, because in many cases a screensaver still requires the display's backlight to be on. You can set the interval to turn the display off in Windows' Power Options—found in the Control Panel.
Extending the Overall Life
The easiest way to give your battery an early death is to damage it. And the two most common causes of damage are from overheating and overloading. Here's how you prevent overheating:
1. Use a cooling pad when using a notebook computer on your lap.
2. Avoid propping your laptop on a pillow, blanket, or other soft surface that can heat up.
3. Clean your desk. It sounds strange, but if you have a dusty, dirty desk, that dust will get into the vents and clog the cooling fan. Once the dust is inside your laptop, it is much harder to remove. You can try blasting it out with canned air, but you run the risk of damaging internal components. You can also remove the vent and clean out the grit, but remember that taking apart your laptop can void the warranty. So clean your desk at least once a week, if not daily.
4. Never store your laptop in a place where the air temperature exceeds 80 degrees Fahrenheit, such as a hot car or an outdoor patio.
5. Consider taking your battery out when using your laptop plugged into AC power. Just make sure to keep the contacts clean. If you need to clean them, use rubbing alcohol.
6. For lithium ion batteries, you do not need to discharge them fully and recharge constantly. Since they don't have the same "memory" as older nickel-metal hydride batteries, it is actually better to discharge a lithium ion only partially before recharging. You need to do a full discharge only about every 30 charges.
Overloading a battery occurs when you use an AC adapter that has a higher wattage than that specified on the laptop (and battery), or if the circuitry of the laptop consistently overcharges the battery. If you're using a replacement or spare adapter, make sure the wattage matches your laptop's within the specified voltage range. In the worst-case scenario, overloading can also damage your motherboard.
Picking a Laptop for Maximum Battery Life
If you're in the market for a new laptop, there are features and components you should consider to get the most mileage from the system's battery.
1. An ultra-low-voltage processor, such as the Intel Penryn or one from VIA's line of ULV processors.
2. A solid-state storage drive, which requires less power and, since there are no spinning parts, will suffer less wear and tear than a traditional hard drive.
3. An LED display. Although pricey, LEDs use much less power than LCD.
4. A smaller screen. A smaller screen means a smaller backlight, which will also save on battery drain.
According to Andrew Bradner, product line manager for APC, all lithium ion batteries are not created equal. The proof is in the pudding, or in this case the chemistry. Unfortunately, it is almost impossible to discern if the battery you're buying was manufactured in a top-notch facility using high-quality materials. And making that call is not as easy as assuming your laptop manufacturer's battery will be of better quality than a battery from a third-party vendor. But you can stick to a couple of key guidelines.
1. Don't skimp on your battery. If you choose the lowest-cost battery you'll probably get a battery that degrades quickly, and you'll end up buying a replacement too soon anyway. So spend the money now to save expense and frustration down the road.
2. Don't buy an expired battery. A good indicator of a battery's performance is how far into its product life it is, whether it's used or new. If possible, look at the bottom of the battery and find the manufacture date.
Thursday, October 09, 2008
Restore Lost Favorites
If you're lucky, your Internet Explorer bookmarks are still in the Recycle Bin. Double-click the Recycle Bin icon on the desktop and select the Details view (the one that shows a row of information for each file). Click the Type column header to sort by file type. Look for files whose type is Internet Shortcut. When you find some that match your missing Favorites, right-click them and choose Restore. Some people organize their Favorites into submenus, which are stored as folders. If your Favorites included submenus you'll need to look through the items of type File Folder and restore any of those that came from your list of Favorites.
If the files aren't in the Recycle Bin you're pretty much out of luck. One thing you can do to recover the ones you use most is open the History panel in Internet Explorer, and revisit the sites you recognize as Favorites, then add them.
For the future you should create a user account for your grandson and log him in separately when you want to let him use the computer. Then unless he's a computer whiz he'll only be able to delete his own Favorites!
Source : http://www.pcmag.com/
If the files aren't in the Recycle Bin you're pretty much out of luck. One thing you can do to recover the ones you use most is open the History panel in Internet Explorer, and revisit the sites you recognize as Favorites, then add them.
For the future you should create a user account for your grandson and log him in separately when you want to let him use the computer. Then unless he's a computer whiz he'll only be able to delete his own Favorites!
Source : http://www.pcmag.com/
Subscribe to:
Posts (Atom)
