Monday, 21 January 2013

Design for print and web/ ISTD/ Quick response code

Ever seen those black and white checkered boxes on Android web sites? They’re QR or “Quick Response” codes, and they can be read from your phone using the Barcode scanner application from the Android Market. You can scan the codes that are published on web sites and use the results for all kinds of things. QR codes can be encoded with any short piece of text. This application will allow you to browse to a URL, save a contact, or copy the text to use in another application.
First, you use the app by opening it and holding the phone as if you’re taking a picture of the QR code. Here’s one that goes to the front page of Make Tech Easier:
There’s a box with a red line that gives you an idea of how to center the code.
Hold steady and… BEEP! The code has been interpreted. The app will give you options according to its best guess as to what the code is. If it’s a URL, it will give you the option of opening it in the browser. If it’s ordinary text, it will let you use it as a Google search or send it as an SMS message.
URLs are by far the most common use for QR codes on Android. If a web site wants to publish a link that should be viewed on the phone, or the link is to the Android Market, the QR code is an easy way to transfer this data to viewers’ phones. There’s no laborious typing it in on a tiny keyboard. Just scan and click.
If you’d like to create your own for a web site, business card, poster, flier, or tattoo, you can create one very easily by going to one of the many online QR code generators. is one of these and it couldn’t be easier. Just type in the text that you’d like to appear in the code, choose small, medium, large, or extra large and hit enter. Then save the image to your hard drive by right clicking and going to “Save Link as…” (Firefox). There’s also a permalink to the image that will appear the box right below it.
The Barcode Scanner app will also let you transfer data from one phone to another similar to the old infrared contact swap on Palm Pilots. Go to menu, then “Share” and choose a contact, bookmark, or the the contents of your clipboard. A QR code representing the data will appear on your screen. The person you’re transferring to then scans the screen of your phone.


Design for print and web/ ISTD/ 10 mistakes not to make

1. Don’t Begin Wireframes or Designs Without a Flowmap

Have a well-thought-out user flow ready to go before wireframes and designs begin. Even simple applications should have a well-considered flowmap in place to help ensure a logical and reasonable navigational structure.
Another thing to pay attention to is making sure that key functional screens are close to the top rather than buried beneath multiple levels of navigational elements. Skipping the flowmap and simply designing or wiring screens without a plan is the easiest way to create a convoluted flow that leaves users confused and turned off.

2. Don’t Disregard the Development Budget
Everything a designer creates will have to go through a developer in order to bring those designs to life. Sometimes very simple design changes can make the difference between a feature that takes a few hours to build and one that takes a few days. Be weary of over-defining functionality in the design.
In other words, the design should not dictate the functionality. For example, an app might have been planned to have a search box, one the designer envisions with a type-ahead search that generates live results as the user types. But this can be a significant developmental undertaking to properly implement, and the designer should not be the sole decision-maker for such a significant element.

3. Don’t Start With Low Resolutions & Avoid Bitmaps
Always design for retina, high-res, pixel-dense screens first, then scale down. This should be obvious to any serious designer but it’s still worth mentioning. As the number of common screen resolutions on mobile devices continues to expand (iOS alone has 4 different resolutions to worry about), always start with the highest resolution device and scale down from there. Even better: Design with vector graphics rather than scale-challenged bitmaps or rasterized graphics.

4. Don’t Undersize The Hit Area
Remember that most users' index fingers are 1.6 to 2 cm wide. Take into account the width of a finger, plus the fact that users are moving quickly and aren’t able to reliably tap a tiny area of the screen. It’s all too easy to pack lots of buttons and functionality into a screen, but be sure to always make buttons big enough — and spaced enough — to be easily tapped by users.

5. Don’t Gratuitously Use Intro Animations
Those fun little animations when an app first opens can be really nice, but it’s important not to go overboard with them. The catch with intro animations (Path and Thrillist’s JackThreads have cool ones) is that they technically can’t begin until the app is already loaded. So in effect, they actually delay the user from accessing the app. If you’re going to use one, make it quick, subtle and appealing enough to be worth the extra second or so that the user has to wait.
As an app loads, a still image should display, which then transitions into an animation. Make sure the transition is seamless. Some poor implementations have a jump or glitch as the app transitions from the still loading image to the intro animation, and that’s no fun.

6. Don’t Leave Users Hanging
Leaving the user out of the loop when the app is loading or processing could cause users to think the app is malfunctioning. It’s also just a poor experience.
Don't keep your users waiting on a blank screen while the app is loading content from the web. Use loading indicators and animations to give users a heads up that the app is working, but it’s just waiting on the phone or the network. A progress indicator is even better, but it’s worth checking with your developers or having a backup plan before designing them into the interface (per our second tip).

7. Don’t Blindly Copy Style From Other Operating Systems

Bad conversions from one mobile OS to another can confuse and annoy users. Every mobile OS has its own style and the OS’s creator has probably published detailed Human Interface Guidelines that have codified their unique aesthetic. iPhone, Android and Windows Phone 7 have very different aesthetics. For example, an app on the iPhone that uses the WP7’s block-layout and navigation style would be unfamiliar and confusing to users.
It’s not necessary to make every app look like it was built by the operating system’s creator, but be careful not to make the app look like it doesn’t belong on the platform.

8. Don’t Overstuff Pixel-Dense Screens
When designing for high PPI (pixel per inch) displays, there can be a temptation to fit more into an interface because you have more pixels to play with. This is especially true if you're reviewing designs on an 27-inch high-res display, where even the most busy interfaces will have plenty of room to breathe. Remember to preview all your work on the actual device you're designing for, even if it’s just a screengrab in the device’s photo viewer.
Overstuffing an interface can result in an app that's cluttered and difficult to navigate. In the worst cases, critical parts of the interface may actually be downright impossible to see.

9. Don’t Assume Everyone Will Use Your App The Same Way You Do
Usability testing is a must, no matter how good your app looks. Consider organizing a closed beta to small group of trusted people (including a few experienced designers) and update the interface before releasing the app to the public.
Another easy way to get some decent feedback on the cheap is to put up a Craigslist ad for a testing focus group. Target college students who would be willing to come in and play around with a pre-release app in exchange for a few bucks and some pizza.

10. Don’t Forget About Gestures, But Don’t Abuse Them Either
Keep in mind that not every single element of the interface has to be fully visible or easy to get to immediately.
A great example is the deletion process in the Mail app for iPhone. In the inbox view, a user can swipe a message to reveal a delete button. This is a shortcut that saves the user the hassle of tapping “edit,” selecting a message to delete and then tapping delete. But it’s a balance: The “delete” shortcut is a way to quickly remove an email, while the “edit” menu is reserved for those who don’t know about the shortcut or who want to take advanced actions such as deleting or flagging multiple messages at a time.
In other words, keep gestures in mind, but don’t become overly reliant on them. And generally avoid using a gesture-accessed menu or action as the only point of access.

If there’s a single unifying element to all these design faux pas, it’s that the best designs are carefully considered. It comes down to thinking critically and completely about your methods. Really think through what your users are trying to achieve and let that inform your designs. Don’t cut corners, don’t skip testing and don’t create designs that you wouldn't put in your portfolio or use yourself.
Have you built a mobile app before and have some tips on what not to do? Let us know in the comments.

Design for print and web/ ISTD/ A-Z plants

I do Realise that the images listed below only goes from A-C however there is a substantial amount of plants, and as i'm not designing an A-Z dictionary of plants i didn't think it was necessary to blog every living plant, never the less here is just the beginning!