Related
(I work in QA, this really is for legitimate use.)
I'm trying to come up with a way to introduce forced input lag for both keyboard and mouse (in Windows). Like, when I press 'A' on the keyboard, I want to introduce a very slight delay before the OS processes that A. Or if I move the mouse, I'd like the same mouse speed, but just with the same slight delay before it kicks in. This lag needs to be present across any threads, not just the one that kicked off the process. But, the lag doesn't have to be to-the-millisecond precise every time.
I'm not even sure how to go about setting this up. I'm capable of writing it in whatever language/environment we may need, I'm just not sure where to start. I think something like AutoHotkey may be able to do what I want by essentially making an arbitrary key call a macro that delays very slightly before sending that key, but I'm not sure what function calls I may need to make it happen. Or, maybe there's a way in C to get at the input across the OS before it kicks in. I'm just not sure.
Can anyone can point me to some resources or a language/function(s) that can accomplish this? (Or even an already existing program or service.)
If you want purely software solution, I’m afraid you’ll need to develop a filter driver for your keyboard and mouse. Very expensive to develop.
Instead, you can plug your mouse and keyboard into somewhere else, have the input messages come through the network, and then introduce network latency. You could use second PC + VNC software, or second PC + software USB/IP, or hardware USB/IP device like this one.
There’s an easy but less reliable way.
You could develop a system-wide WH_KEYBOARD_LL and WH_MOUSE_LL hooks, discard original messages, and after a while send the delayed messages with SendInput API. This should work mostly, however there’re cases where it wont, e.g. I don’t expect anything happens with most videogames because raw input.
I have an HID device that is somewhat unfortunately designed (the Griffin Powermate) in that as you turn it, the input value for the "Rotation Axis" HID element doesn't change unless the speed of rotation dramatically changes or unless the direction changes. It sends many HID reports (angular resolution appears to be about 4deg, in that I get ~90 reports per revolution - not great, but whatever...), but they all report the same value (generally -1 or 1 for CCW and CW respectively -- if you turn faster, it will report -2 & 2, and so on, but you have to turn much faster. As a result of this unfortunate behavior, I'm finding this thing largely useless.
It occurred to me that I might be able to write a background userspace app that seized the physical device and presented another, virtual device with some minor additions so as to cause an input value change for every report (like a wrap-around accumulator, which the HID spec has support for -- God only knows why Griffin didn't do this themselves.)
But I'm not seeing how one would go about creating the kernel side object for the virtual device from userspace, and I'm starting to think it might not be possible. I saw this question, and its indications are not good, but it's low on details.
Alternately, if there's a way for me to spoof reports on the existing device, I suppose that would do it as well, since I could set it back to zero immediately after it reports -1 or 1.
Any ideas?
First of all, you can simulate input events via Quartz Event Services but this might not suffice for your purposes, as that's mainly designed for simulating keyboard and mouse events.
Second, the HID driver family of the IOKit framework contains a user client on the (global) IOHIDResource service, called IOHIDResourceDeviceUserClient. It appears that this can spawn IOHIDUserDevice instances on command from user space. In particular, the userspace IOKitLib contains a IOHIDUserDeviceCreate function which seems to be supposed to be able to do this. The HID family source code even comes with a little demo of this which creates a virtual keyboard of sorts. Unfortunately, although I can get this to build, it fails on the IOHIDUserDeviceCreate call. (I can see in IORegistryExplorer that the IOHIDResourceDeviceUserClient instance is never created.) I've not investigated this further due to lack of time, but it seems worth pursuing if you need its functionality.
We have a legacy PowerBuilder 12.1 Classic application with an Oracle 11g back end, and are experiencing performance issues in production that we cannot reproduce in our test environments.
The window in question has shared grid/freeform DataWindows and buttons to open other response windows, which when closed cause the grid to re-retrieve.
The grid has a very expensive query behind it, several columns receive their values from function calls with some very intense SQL within, however it still runs within a couple seconds, even in production.
The only consistency in when the errors occur is that it seems to be more likely if they attempt to navigate to the other windows quickly. The buttons that open said windows are assuming that a certain instance variable is set with the appropriate value from the row in focus in the grid. However, in this scenario, the instance variable has not yet been set, even though it looks like the row focus change has occurred. This is causing null reference exceptions that shouldn't be possible.
The end users' network connectivity is often sluggish, and their hardware isn't any less capable than ours. I want to blame the network, but I attempted to reproduce this myself in development by intentionally slowing down the SQL so that I could attempt to click a button, however everything happened as I expected: clicking the button didn't happen until after retrieve and all the other events finished.
My gut tells me that for some reason things aren't running synchronously when they should, and the only factor I can imagine is the speed of the SQL, whether from the query being slow, or the network being slow, but when I tried reproducing that effect things still happened in the proper sequence. The only suspect code is that the datawindow ancestor posts a user event called ue_post_rfc from rowfocuschanged, and this event does a Yield(). ue_post_rfc is where code goes instead of rowfocuschanged.
Is there any way Yield() would cause these problems, without manifesting itself in test environments, even when SQL is artificially slowed?
While your message may not give enough information to give you a recipe to solve your problem, it does give me a hint towards a common point of hard-to-diagnose failures that I see often in PowerBuilder systems.
The sequence of development events goes something like this
Developer develops code where there is a dependence on one event firing before another event, often a dependence through instance or global variables
This event sequence has been something the developer has observed, but isn't documented as a guaranteed sequence (like the AcceptText() sequence or the Update() sequence are documented)
I find this a lot with posted events, and I'm not talking about event and post-event where post-event is posted from event, but more like between post-ItemChanged and post-GetFocus
Something changes the sequence of events, breaking the code. Things that I've seen change non-guaranteed sequences of events include:
PowerBuilder version change
Operating system change
Hardware change
The application running with other applications taxing the system resources
Whoever is now in charge of solving this, has no clue what is going on or how to deal with it, so they start peppering the code with Yield() statements (I've literally seen comments beside a Yield() that said "I don't know why this works, but it solves problem X")
Note that Yield() allows any and all events in the message queue to be processed, while this developer really wants only one particular event to get through
Also note that the commonly-seen-in-my-career DO ... LOOP UNTIL (NOT Yield()) could loop infinitely on a heavily loaded system
Something happens to change the event sequence again
Now when the Yield() occurs, there is a different sequence of messages in the queue to be processed, and not the message the developer had wanted to be processed
Things start failing again
My advice to get rid of this problem (if this is your problem) is to either:
Get rid of the cross-event dependence
Get rid of event sequence assumptions
Manage the event sequence yourself
Good luck,
Terry
P.S. Here's a couple of quotes from your question that make me think of Yield() (not that I don't love the opportunity to jump all over Yield() grin)
The only consistency in when the errors occur is that it seems to be
more likely if they attempt to navigate to the other windows quickly.
Seen this when the user tries to initiate (let's say for example) two actions very quickly. If the script from the first action contains a Yield(), the script from the second action will both start and finish before the first action finishes. This can be true of any combination of user actions (e.g. button clicks, menu clicks, tabs, window closings... you coded with the possibility that the window isn't there anymore after the Yield() was done, right? If not, join the 99% of those that code Yield(), don't, and live dangerously) and system events (e.g. GetFocus, Deactivate, Timer)
My gut tells me that for some reason things aren't running
synchronously when they should
You're right. PowerBuilder (unless you force it) runs synchronously. However, if one event is starting before another finishes (see above), then you're going to get behaviours that look like asynchronous behaviours.
There's nothing definitive in what you've said, but you did ask about Yield(). The really kicker to nail this down is if you could reproduce this with a PBDEBUG trace; you'd see which event(s) is(are) surprising you. However, the amount that PBDEBUG slows things down affects event sequences and queuing, which may or may not be helpful.
I'm a software developer who has a background in usability engineering. When I studied usability engineering in grad school, one of the professors had a mantra: "You are not the user". The idea was that we need to base UI design on actual user research rather than our own ideas as to how the UI should work.
Since then I've seen some good examples that seem to prove that I'm not the user.
User trying to use an e-mail template authoring tool, and gets stuck trying to enter the pipe (|) character. Problem turns out to be that the pipe on the keyboard has a space in the middle.
In a web app, user doesn't see content below the fold. Not unusual. We tell her to scroll down. She has no idea what we're talking about and is not familiar with the scroll thumb.
I'm listening in on a tech support call. Rep tells the user to close the browser. In the background I hear the Windows shutdown jingle.
What are some other good examples of this?
EDIT: To clarify, I'm looking for examples where developers make assumptions that turn out to be horribly false about what users will know, understand, etc.
I think one of the biggest examples is that expert users tend to play with an application.
They say, "Okay, I have this tool, what can I do with it?"
Your average user sees the ecosystem of an operating system, filesystem, or application as a big scary place where they are likely to get lost and never return.
For them, everything they want to do on a computer is task-based.
"How do I burn a DVD?"
"How do I upload a photo from my camera to this website."
"How do I send my mom a song?"
They want a starting point, a reproducible work flow, and they want to do that every time they have to perform the task. They don't care about streamlining the process or finding the best way to do it, they just want one reproducible way to do it.
In building web applications, I long since learned to make the start page of my application something separate from the menus with task-based links to the main things the application did in a really big font. For the average user, this increased usability hugely.
So remember this: users don't want to "use your application", they want to get something specific done.
In my mind, the most visible example of "developers are not the user" is the common Confirmation Dialog.
In most any document based application, from the most complex (MS Word, Excel, Visual Studio) through the simplest (Notepad, Crimson Editor, UltraEdit), when you close the appliction with unsaved changes you get a dialog like this:
The text in the Untitled file has changed.
Do you want to save the changes?
[Yes] [No] [Cancel]
Assumption: Users will read the dialog
Reality: With an average reading speed of 2 words per second, this would take 9 seconds. Many users won't read the dialog at all.
Observation: Many developers read much much faster than typical users
Assumption: The available options are all equally likely.
Reality: Most (>99%) of the time users will want their changes saved.
Assumption: Users will consider the consequences before clicking a choice
Reality: The true impact of the choice will occur to users a split second after pressing the button.
Assumption: Users will care about the message being displayed.
Reality: Users are focussed on the next task they need to complete, not on the "care and feeding" of their computer.
Assumption: Users will understand that the dialog contains critical information they need to know.
Reality: Users see the dialog as a speedbump in their way and just want to get rid of it in the fastest way possible.
I definitely agree with the bolded comments in Daniel's response--most real users frequently have a goal they want to get to, and just want to reach that goal as easily and quickly as possible. Speaking from experience, this goes not only for computer novices or non-techie people but also for fairly tech-savvy users who just might not be well-versed in your particular domain or technology stack.
Too frequently I've seen customers faced with a rich set of technologies, tools, utilities, APIs, etc. but no obvious way to accomplish their high-level tasks. Sometimes this could be addressed simply with better documentation (think comprehensive walk-throughs), sometimes with some high-level wizards built on top of command-line scripts/tools, and sometimes only with a fundamental re-prioritization of the software project.
With that said... to throw another concrete example on the pile, there's the Windows start menu (excerpt from an article on The Old New Thing blog):
Back in the early days, the taskbar
didn't have a Start button.
...
But one thing kept getting kicked up
by usability tests: People booted up
the computer and just sat there,
unsure what to do next.
That's when we decided to label the
System button "Start".
It says, "You dummy. Click here." And
it sent our usability numbers through
the roof, because all of a sudden,
people knew what to click when they
wanted to do something.
As mentioned by others here, we techie folks are used to playing around with an environment, clicking on everything that can be clicked on, poking around in all available menus, etc. Family members of mine who are afraid of their computers, however, are even more afraid that they'll click on something that will "erase" their data, so they'd prefer to be given clear directions on where to click.
Many years ago, in a CMS, I stupidly assumed that no one would ever try to create a directory with a leading space in the name .... someone did, and made many other parts of the system very very sad.
On another note, trying to explain to my mother to click the Start button to turn the computer off is just a world of pain.
How about the apocryphal tech support call about the user with the broken "cup holder" (CD/ROM)?
Actually, one that bit me was cut/paste -- I always trim my text inputs now since some of my users cut/paste text from emails, etc. and end up selecting extra whitespace. My tests never considered that people would "type" in extra characters.
Today's GUIs do a pretty good job of hiding the underlying OS. But the idosyncracies still show through.
Why won't the Mac let me create a folder called "Photos: Christmas 08"?
Why do I have to "eject" a mounted disk image?
Can't I convert a JPEG to TIFF just by changing the file extension?
(The last one actually happened to me some years ago. It took forever to figure out why the TIFF wasn't loading correctly! It was at that moment that I understood why Apple used to use embedded file types (as metadata) and to this day I do not understand why they foolishly went back to file extensions. Oh, right; it's because Unix is a superior OS.)
I've seen this plenty of times, it seems to be something that always comes up. I seem to be the kind of person who can pick up on these kind of assumptions (in some circumstances), but I've been blown away by what the user was doing other many times.
As I said, it's something I'm quite familiar with. Some of the software I've worked on is used by the general public (as opposed to specially trained people) so we had to be ready for this kind of thing. Yet I've seen it not be taken into account.
A good example is a web form that needs to be completed. We need this form completed, it's important to the process. The user is no good to us if they don't complete the form, but the more information we get out of them the better. Obviously these are two conflicting demands. If just present the user a screen of 150 fields (random large number) they'll run away scared.
These forms had been revised many times in order to improve things, but users weren't asked what they wanted. Decisions were made based on the assumptions or feelings of various people, but how close those feelings were to actual customers wasn't taken into account.
I'm also going to mention the corollary to Bevan's "The users will read the dialog" assumption. Operating off the "the users don't read anything" assumption makes much more sense. Yet people who argue that the user's don't read anything will often suggest putting bits of long dry explanatory text to help users who are confused by some random poor design decision (like using checkboxes for something that should be radio buttons because you can only select one).
Working any kind of tech support can be very informative on how users do (or do not) think.
pretty much anything at the O/S level in Linux is a good example, from the choice of names ("grep" obviously means "search" to the user!) to the choice of syntax ("rm *" is good for you!)
[i'm not hatin' on linux, it's just chock full of unix-legacy un-usability examples]
How about the desktop and wallpaper metaphors? It's getting better, but 5-10 years ago was the bane of a lot of remote tech support calls.
There's also the backslash vs. slash issue, the myriad names for the various keyboard symbols, and the antiquated print screen button.
Modern operating systems are great because they all support multiple user profiles, so everyone that uses my application on the same workstation can have their own settings and user data. Only, a good portion of the support requests I get are asking how to have multiple data files under the same user account.
Back in my college days, I used to train people on how to use a computer and the internet. I'd go to their house, setup their internet service show them email and everything. Well there was this old couple (late 60's). I spent about three hours showing them how to use their computer, made sure they could connect to the internet and everything. I leave feeling very happy.
That weekend I get a frantic call, about them not being able to check their email. Now I'm in the middle of enjoying my weekend but decide to help them out, and walk through all the things, 30 minutes latter, I ask them if they have two phone lines..."of course we only have one" Needless to say they forgot that they need to connect to the internet first (Yes this was back in the day of modems).
I supposed I should have setup shortcuts like DUN - > Check Email Step 1, Eduora - Check Email Step 2....
What users don't know, they will make up. They often work with an incorrect theory of how an application works.
Especially for data entry, users tend to type much faster than developers which can cause a problem if the program is slow to react.
Story: Once upon a time, before the personal computer, there was timesharing. A timesharing company's customer rep told me that once when he was giving a "how to" class to two or three nice older women, he told them how to stop a program that was running (in case it was started in error or taking to long.) He had one of the students type ^K, and the timesharing terminal responded "Killed!". The lady nearly had a heart attack.
One problem that we have at our company is employees who don't trust the computer. If you computerize a function that they do on paper, they will continue to do it on paper, while entering the results in the computer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are some key UI design tips that every developer should know?
While there are a number of UI resources for developers (for example, Joel Spolsky's User Interface Design for Programmers), I'm interested in more of a bullet list that can be communicated in 1 to 2 pages.
I'm interested in more tactical, day-to-day UI tips, as opposed to overarching UI design goals that would be covered in a UI design meeting (presumably attended by at least one person with a good UI sense). A collection of these tips might cover about 80% of the cases that an everyday programmer would come across.
use a standard menubar (amateur GUI designers seem to like to chart their own course here for some reason). Make sure the first items are File, Edit and View, and the last one is Help
don't worry about color themes or skins; stick to a standard look that is consistent with your platform
use the default system font
use menu accelerators that are consistent with your platform
stick to the tried and true layout with a menubar on top, a status bar on the bottom, and if required, a navigation pane on the left
never do a system-wide grab
If you have a choice, make all windows resizable.
use groups of radiobuttons for "choose exactly one". Always make sure one of them is selected by default. If you want the user to be able to not choose any, add another radiobutton for "no choice"
use groups of checkbuttons for "choose zero or more"
constrain input if necessary (ie: simply ignore non-digits in a numeric input field) rather than waiting for a user to enter data, submit, then throw up a dialog saying "hey, letters aren't allowed!". If they aren't allowed, don't accept them in the first place.
be liberal in what you accept as input. For goodness sake, don't throw a fit for a SSN field if they leave out the hyphens, or put then in when you don't want them. The computer is smart, let it figure out that xxxxxxxxx and xxx xx xxxx and xxx-xx-xxxx are all valid social security numbers.
always allow spaces in long fields such as serial numbers and whatnot. Data quality goes way up if a user is allowed to group numbers in sets of three or four. If your data model can't handle the spaces you can remove them before saving the data.
Avoid pop-up dialogs like the plague. Never display one unless you absolutely must. If you decide you must, stop and rethink your design before continuing. There are times when they are necessary, but those times are considerably less frequent than you might imagine.
pay attention to keyboard traversal. Most toolkits make an attempt to get it right, but always double-check. A use should be able to use the tab key to traverse the widgets in a logical manner.
All of these rules can, of course, be broken. But only break it if you are breaking it for a justifiable reason.
Remember, the software is there to aid the user, it should be doing what they want, rather than making them do what it wants.
When you are about to perform an action that will change or delete information, don't ask 'are you sure' - users will learn to click the button as part of the action. Try to allow for an 'Undo' in the system design.
Make the default choice the one most users would be happy with.
Always give your user a "way out" from wherever they are that does not require the use of the back button.
The best example:
If an error occurs, give them a link back to where they were (or at least to where they can start over).
Use tool tips as much as possible. It is amazing how these little guys can add a large amount of help to the end user and they are unobtrusive to the application itself.
When designing a UI make it as simple as possible, but no simpler.
ask the user, don't just make things up
simplify - remove a step, eliminate clicks, etc.
get familiar with the principles of usability
I think that this link would be a good starting point, from Microsoft's "Windows Vista User Experience Guidelines:
http://msdn.microsoft.com/en-us/library/aa511328.aspx
And this might be very close to the two page bullet point list you are looking for: "Top Violations":
http://msdn.microsoft.com/en-us/library/aa511331.aspx
Very down to earth tips like: "Set a minimum window size if there is a size below which the content is no longer usable."
Correct tab-stops are a must.
Do not increase "discoverability" at the cost of basic clarity and usability.
Find the thing the user will do the most often, and then make that the easiest thing to do.
For example: I have a long running personal gripe with microwave design.
Many require you to set a clock you never use for anything prior to using the microwave, and it forgets everytime it loses power AND requires 10 key-presses on those hard-to-use button pads to do so.
A simple usability test would realize the most common cook time used on microwaves is the standard 'minute' and multiples thereof. An Ideal microwave should thus be able to cook an product for 1 minute on high power in 3 or less actions.
For times outside a minute, but within 5 minutes of the golden "1" minute, there should be slightly more steps, but not significantly so, and only significant numbers of actions required for cook times > 5 minutes. ( which are rather rare )
2 examples of great microwave design
1. 4 parts. Door, temperature dial, time dial, time-lighting sequence
Temperature dial is analogue and persists from previous setting, with a varying sliding range.
Time dial is digital, but simulated analogue, turning dial clockwise increases clock time( shown by a lighting sequence under the dial). Turning dial counter clockwise decreases clock time. Cooking decreases clock time.
Door being closed and time being on clock starts cooking. Door opening pauses cooking.
standard operation: open door, load, turn time dial, close door ( or optionally, close door first, and cooking starts as soon as >1s is on clock )
2. 6 Parts, Door, Dial, Power Button, Start Button, Clear Button, Digital Time Display
Start button with no time chosen starts cooking for 1 minute on high power.
Start button while cooking adds 1 minute to time.
Time dial persists between sessions. Turning dial causes the time stored on the dials position being copied to the digital timer.
Pressing "power" prior to starting cooking will
in the event the dial has not been turned, copy the current time stored on the dails position to the digital timer.
in the event the dial has been turned, decrements the choice of power level by 1, or if on lowest power level, return to highest.
Pressing power while cooking decrements the power level on the fly.
standard operation:
1 minute high = press start.
1 minute medium high = press start, press power.
2 minutes high = press start twice.
<anytime> on high = turn dial until happy, press start.
<anytime> on <anypower> turn dial until happy, press power until happy, press start.
<previously chosen time> on high = press power, press start
<previously chosen time + 1 minute> on high = press power, press start twice.
As you can see here, adding a small amount of extra buttons, can add a great degree of expressive and functional design.
Any design with a numeric keypad for time specification, tends to fail my criteria for good design.
Its noted that these designs may, for some people have a higher learning curve, but once learned, muscle memory makes it instinctive. As opposed to more ( obvious? ) but overly complicated designs which even a learned user will repeatedly have to spend tedious amounts of time performing tedious arbitrary operations, simply to attain common goals.
Do some hallway usability testing (in the same way you would do code reviews).
Even a really quick "Hey! try this" usability test (if you can call it that) with the guy next to you will make a big difference. The main thing is to have somebody other than yourself try the bit of UI you've just built.
It's amazing how many times other people get stuck using your new UI, and it only takes a couple of minutes (usually) to find the biggest problems.
If you do use a popup from an editor, make sure to return your insertion point or state to whatever it was before the popup. Too many programs just leave you "hanging" and having to find your way back.
Instead of the arbitrary "OK" and "Cancel" buttons, which, given context, can be ambiguous, and users blindly click one, the buttons should contain a brief description of what they do.
[Ok, Please Cancel my subscription ], [ Please do not cancel my subscription ]
is far better than
Cancel my subscription?
[ OK ] [ Cancel ]
( these sort of failures often surface on the dailywtf )
Minimize number of clicks
Uniform look(text size, buttons.. and other controls )
Minimize free edits... (ex: in an address entry... provide states in a dropdown...etc etc)
In a drop down for country list... list the residing country first...(how many of you frustrated with USA being listed at the bottom and you have to scroll down?)
General drop downs can be ordered as the users choice
No Spelling msitake ;) at all
Pay attention to labeling text: for email address (have the caption as email... believe me... i have seen it as e_mail address:)
Currency symbol for amounts. uniform digit display in amount.. ex:
$12.15 ==> $12.15
$10.9 ==> $10.90
9.Progress/Status bar
Buddy label to indicate the error field before the user clicks OK/Save button(ex: for an email address if there is no "#" there is no need to wait until user clicks OK then tell them invalid email Address)
Avoid repeated inputs... (ex: remember me option in login screen)
global application option to let the user continue from where left off in the previous instance)
when showing data on a grid... excel style filter options
default values for inputs.
Folks...feel free to flush down any of the point above with the valid reasons!!!
Grandmaw Testing.
This is my term for the conceptual question, "Can your grandma, who's never used a computer beyond email and checking www.cutecats.com, use it?(Assuming that she has the real-world knowledge to use that particular app)".
Everything common should be obvious; nothing should be black box magic with side effects. Uncommon things should be accessible in a common format that the user has used before.
Clear labeling, clear route to a help file, clear actions with clear effects.
If Grandma can't use your Paint program, you need to really think about your UI.
My basic rule of UI design is to have each "page" do one task and one task only. It keeps pages simple, which keeps design clean and makes the application more understandable.
This type of design is called Inductive User Interface. Here is a document that Microsoft put out in 2001 on the topic. The text may be a little dated, but the principles are generally pretty good. The only caveat is that there is a balance to be found in designing like this. If you oversimplify too much users will have to navigate all over the place to accomplish simple tasks, and the gains in understandability will be lost to underproductivity.
Some simple tips for daily user interface web design and application design:
Use simple static sketches to begin preliminary web app development plans.
-Dont allow users too many choices. instead, use cater design to send users down a path they'll benefit from.
-Define key user groups and the journeys they made
-Practice iterative design as a part of UI to ensure ROI
I like to follow these guidlines:
Standard - follow known standards/patterns, reuse ideas from all products you respect
Simple - keep your solutions simple and easy to change (if needed)
Elegant - use less to accomplish more