Tag: kranthi

Free Download: Cheat Sheet For Designing Web Forms





 



 


Forms, forms, forms: so often overlooked in design. In this post, we are pleased to release the Form Design Cheat Sheet, created by Joe Leech and released for Smashing Magazine and its readers. This crib sheet contains an Omnigraffle template, as well as Photoshop (PSD) and PDF examples for you to download and use as you wish. Print out the sheet, stick it to your wall, send it to clients, and just generally help make everyone’s forms a bit better.

The designers of the crib sheet have spent years designing and testing forms, and they’ve decided to summarize the most common problems and issues that come up in their projects.

As usual, this goodie is absolutely free to use in private and commercial projects. The crib sheet is released under a Creative Commons license.

Form Design

Form Design Cheat Sheet: Full preview

Features

The crib sheet presents best practices for a variety of Web form issues:

  • Variety of fields (simple, optional, etc.);
  • Layout and examples;
  • Page-level error handling;
  • Password strength;
  • Currency values;
  • Inline validation;
  • Buttons.

Download The Crib Sheet For Free

The crib sheet is released under a Creative Commons license. You can use it in all of your projects for free and without any restrictions. Please link to this article if you would like to spread the word. You may modify the theme as you wish. We know you’ll find it useful in your next project!

Thank you, guys. We appreciate your work and your good intentions!

(al) (fi) (il)


© Joe Leech for Smashing Magazine, 2011.


Not Your Parent’s Mobile Phone: UX Design Guidelines For Smartphones





 



 


In your pocket right now is the most powerful “remote control� (as Drew Diskin put it) that has ever existed. It is no ordinary remote control. It can harness everything that all of the previous mass media (television, radio, Internet, etc.) can do. People aren’t using them just for simple entertainment or for phone calls. They have become the hub of our personal lives.

Smartphones are what younger generations know as just phones. The iPad (aka the tablet) is giving your grandma’s PC a run for its money. You certainly are holding some amazing futuristic technology in your hands. It will be even better tomorrow, though, so why does it matter to us or to users? Moore’s Law tells us, in effect, that these things will continue to become capable of more than anything our minds can think up.

Two smartphone users

(Image: Denis Dervisevic)

It’s no longer just about the evolving power and capabilities of these devices. It’s about us and how we, too, are changing. The user’s expectation of a great experience is the new standard. It falls to us as UX professionals to apply our skills to make this happen on the vast array of devices out there. It’s not always easy, though. The mobile realm has some unique constraints and offers some interesting opportunities. While covering all of the nuances of mobile UX in one article would be impossible, we’ll cover some fundamentals and concepts that should move you in the right direction with your projects.

Mobile Constraints

The mobile realm has many constraints. Here are several of them, along with thoughts on what to keep in mind as you come upon them.

Form Factor

The most obvious constraint going from desktop to mobile is screen size. Mobile screens are smaller. A lot smaller. You need to seriously consider this when designing and developing your application. Antony Ribot makes a good point in his presentation, “Mobile UX: The Intricacies of Designing For Mobile Devices,� when he says, “Mobile is not about making things smaller.� It’s much more than that. We need to consolidate what’s on the screen. Boil the application down to the most critical functions and content, and then lay them out strategically in the available screen space. For example, action buttons should go in the lower third of the screen, where they are most easily tappable.

Input Methods

Another obvious constraint is the absence of or difference in certain input mechanisms, and the addition of others. First, there’s no mouse. No mouse means no hover states. It also means that there must be some other means of clicking and navigating content. In most cases, this other means is the user’s finger. This difference in input method can be quite exciting because it opens the door to new possibilities with various gestures. Many standards are forming around these new gesture capabilities: pinch to zoom, swipe to scroll, etc. Take the time to include support for these gestures in your application. In addition, think of new gestures that you could add to enhance interactivity.

Discovering new gestures can be a powerful experience for users. It adds a sense of excitement, mystery and achievement — “Hey, I just figured out something new!� Take care, though, not to change the function of standard gestures unless you have a very good reason to do so, or else you will cause unnecessary confusion and frustration in users.

Gesture Card

(Touch Gesture Cards (PDF): Luke Wroblewski)

One other caveat: consider the type of application you’re developing before getting too fancy with gestures. If it will be highly utilitarian in nature, then keeping things simple and straightforward would be best. If the application is for a specific task, then users will want to complete it as quickly and easily as possible. They don’t have the time or desire to discover new interactions.

Technical Constraints

While the capabilities of these devices improve with each new release it, keep in mind their limitations. Things like battery life and processing power are important to consider. Draining the battery or bringing the device to its knees with memory leaks or processor-intensive operations is a surefire way to destroy the user experience. This is why testing on the device early and often is imperative. Simulators cannot be trusted.

Data Transfer and Pricing

This will not be an issue for users who have unlimited data plans or who work on Wi-Fi networks. Unfortunately, unlimited plans are becoming increasingly rare. So, be sensitive to the amount of data you are transferring to and from your application. Keep the sizes of assets to a minimum, while maintaining quality. Don’t transfer data unnecessarily. For example, implement delta updates whenever possible (i.e. update only the data that has changed since the last transfer).

Food Sense - Responsive Web Design

(Images: Mediaqueri.es and Food Sense)

Much has been said recently about Responsive Web Design. This approach does create some challenges with minimizing data transfer. Jason Grigsby has a very good write-up on the specifics. To summarize, CSS media queries — part of the magic sauce of responsive design — do almost nothing to lessen the overhead of data transfer to mobile devices. Resizing or hiding unwanted images still requires the full images to be downloaded to the browser. In addition, resources such as JavaScript libraries might be downloaded to mobile devices without even being enabled for users.

Good General Practices

What follows are some good general principles to keep in mind when designing and developing mobile applications.

Mobile First

Luke Wroblewski has a great post on the “Mobile First� methodology. In a nutshell, focusing on mobile first puts your mind in the right place. It forces you to focus on and prioritize the most important features and content in your application. It also extends your abilities by offering new tools and services that are not available in a traditional desktop environment. By approaching your project with the mobile-first mentality, you will start off on the right foot.

Behaviors and Archetypes

Build on the behaviors and archetypes that your users are already accustomed to. This will go a long way to reducing the learning curve of your application. If your application responds predictably to a user’s interaction, then the user will immediately become more comfortable.

This applies to more than general behaviors and archetypes. You will want to use design patterns that are specific to your target devices. This means building multiple interfaces for various devices and platforms, which is extra work; but it will pay off in the long run because users will appreciate that your application behaves in the manner they’ve come to expect from their device. For example, iOS design patterns dictate that tabbed navigation be located at the bottom of the screen, whereas Android devices have it along the top.

As with most good UX principles, if done properly, the user won’t even notice, while their increased comfort level will encourage them to continue exploring the application. Which brings us to our next practice.

Encourage Exploration

The more that users feel comfortable with and enjoy your application, the more likely they will explore it. You may want to lead them down certain paths or provide a few cues or coach marks on how certain things work, but still allow your users to “discover.� I’m not suggesting that you make the application complicated or ambiguous; rather, for example, if there are multiple ways to perform an action, one more obvious and traditional and the other a quick and easy gesture, then the user might come to prefer the second option once they discover it. Such solutions improve the overall experience if they prove to be quicker and more efficient than traditional interactions.

Provide Immediate Feedback

We’ve all witnessed our less computer-savvy peers clicking violently and repeatedly on a button trying to force it to do whatever they so desperately want to achieve. Touchscreens only add to this anxiety because they don’t provide that tactile response that we’ve been conditioned to expect from tapping on a keyboard or clicking with a mouse. Providing some indication that the application has registered the user’s interaction is critical, whether it’s a small bounce at the end of a scrollable region or a subtle color change at the tap of a button. This not only compensates for the lack of tactile response, but assures users that something is happening even if the screen isn’t updating immediately due to slow network traffic or some processor-intensive operation.

Context

Person using a tablet at home

(Image: S. Diddy)

Another glaring difference between mobile and desktop applications is context. With a desktop application, you can be relatively certain that it is being used in a particular environment. With mobile, all bets are off. This gives us some exciting opportunities: location-based services, on-the-spot social networking, the opportunities are vast.

It also raises some unique problems. Do your research to determine the context in which the majority of people will be using your application.

If you’re targeting on-the-go users, then you’ll want to build the application for speed: bold, obvious, stripped-down selectors and a streamlined workflow. If your application is more akin to a breakfast-table browser, then content will probably be more important to the user, but they may have only one hand free to navigate, while the other cradles their morning coffee. These are just two examples; the point is that your mobile application could be used in any number of contexts, and you will need to take the time to figure out how to provide the best experience to the user in their context.

One other thing to consider is the device(s) that you are targeting. Research suggests that a majority of tablet owners use their device mostly at home. Only 21% take their device with them on the go, compared to 59% of smartphone users who consult their device while out and about.

Ideate in the Wild

Crowd of people

(Image: Niall Kennedy)

I’m borrowing this one directly from Rachel Hinman because she is spot on. The best way to determine context and to conduct research is to immerse yourself in the environments in which your application will be used.

Hang out where your target audience hangs out. If possible, do the things they do, go where they go. This will serve a couple purposes. First, it could give you ideas for great applications to build. Maybe you’ll observe common pain points and come up with a solution to alleviate them. Or, if you already have an idea for an application, you could gain valuable insight into how the application might be (or is being) used in the wild. We’d be surprised quite often by the difference between how we intend for our application to be used and how it is actually being used. This information can help us iterate our ideas and continually improve the application.

Conclusion

The way mobile devices are being used is changing all the time, and users are increasingly expecting exceptional experiences from the applications they use. While the mobile world has many constraints, its many more opportunities make building mobile applications a worthwhile venture. Keep in mind the constraints, and focus on mobile first when beginning your project.

Remember that innovative features and cutting-edge design aren’t as valuable to users as we may think. Users are concerned with getting the information they need through a sometimes limited connection, or perhaps getting accustomed to typing on a screen without any tactile feedback. Not everyone has an iPad… yet.

Talk to real people, follow common archetypes, and keep the context of your target users in mind. These guidelines should help you create a great experience in your mobile application.

Additional Resources

Design patterns:

Design guidelines:

Mobile statistics:

Article sources:

(al)


© Tim R. Todish for Smashing Magazine, 2011.


The Smashing Coffee Mug Photo Contest – Join In!





 



 


Here’s a task for you! Have a look at your desk, take a shot of your beloved coffee mug, send us the photo, and see if you’re added to the huge poster that we’ll be creating from the best images that we get from all over the world. We’ll prepare an exclusive version in PDF and print a limited-edition poster (20 copies). If your photo is chosen, your name will be printed on the poster, too. In addition, selected photos will be published in an upcoming Smashing Magazine post. Those with the most creative and original submissions will be awarded with one of the exclusive printed wall posters. We won’t be selling it, of course — but you already knew that.

Submission Guidelines

  • The photo must be in JPG format, at a maximum size of 4000 × 3000 pixels. The file size should not exceed 8 MB.
  • Each participant may send one photo at most.
  • Each photo should show only one mug — not two, three or a dozen.
  • Name your photo with your full name (john-peterson.jpg).
  • Please do not send ZIP, RAR or another archive. Just the plain image.
  • You must own the copyright of the photo you are submitting.
  • Submit your photo to the email address mugs@smashingmagazine.com by 15th of October 2011.

Please note that the coffee mugs must be mugs and not cups! This is important for building a coherent, gripping mosaic. The mugs can be empty or filled, even steaming! Feel free to use any camera you prefer: a toy cam, mobile phone, SLR, point-and-shoot — whatever you have on hand. How many mugs can fit on the poster? We don’t know yet, because it will depend on the quality and originality of the photo you submit!

Some Coffee Mug Inspiration

Need some coffee-mug inspiration? Why not browse through Flickr and Google Images:


Image credit: Terry Johnston


Image credit: Adrian Sampson


Image credit: Ginny


Image credit: Terry Johnston


Image credit: Brendan C.


Image credit: Nina Matthews

Deadline and Announcement

Please submit your photo by October 15th at the latest. The qualifying submissions and the winners will be announced a week later. We will showcase the most interesting photos here on Smashing Magazine (and on the big poster, of course), including the names of the contributors.

Please note: your photo will be used only for this event, and you will retain the full rights to it.

Let’s Go!

On your marks. Ready? Set? Go! Send your photo to mugs@smashingmagazine.com! We look forward to your photos, folks!

 —  The Smashing Team


© Smashing Editorial for Smashing Magazine, 2011.


Styling button elements to look like links

Here’s a common scenario: you’re coding up a form with lots of buttons or need to add some elements that trigger JavaScript functions, and in the design comp some of these elements look like links. You intuitively reach for the a element, put some in the markup, add event handlers to them, and style them to match the design.

But wait a bit. Leaving the issue of putting elements that may rely on JavaScript to work in the markup for another time, should those elements really be links? What does the text on them say? What happens when you click them? If they trigger some kind of action that doesn’t match the normal link behaviour of going to another URL, it’s quite likely that you should really be using buttons.

Yes, I know. The designer says these elements need to look like links, period. And there was a time when making HTML buttons look like links wasn’t really possible in a cross-browser way. But these days you can get very, very close. It’s a bit tricky, but possible.

Read full post

Posted in .

Copyright © Roger Johansson



How To Create Custom Post Meta Boxes In WordPress





 



 


What seems like one of the most complicated bits of functionality in WordPress is adding meta boxes to the post editing screen. This complexity only grows as more and more tutorials are written on the process with weird loops and arrays. Even meta box “frameworks” have been developed. I’ll let you in on a little secret though: it’s not that complicated.

sm-wp_meta-boxes

Creating custom meta boxes is extremely simple, at least it is once you’ve created your first one using the tools baked into WordPress’ core code. In this tutorial, I’ll walk you through everything you need to know about meta boxes:

  • Creating meta boxes.
  • Using meta boxes with any post type.
  • Handling data validation.
  • Saving custom meta data.
  • Retrieving custom meta data on the front end.

Note: When I use the term “post” throughout this tutorial, I’m referring to a post of any post type, not just the default blog post type bundled with WordPress.

What is a post meta box?

A post meta box is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way.

Generally, two types of data is entered into meta boxes:

  • Metadata (i.e. custom fields),
  • Taxonomy terms.

Of course, there are other possible uses, but those two are the most common. For the purposes of this tutorial, you’ll be learning how to develop meta boxes that handle custom post metadata.

What is post metadata?

Post metadata is data that’s saved in the wp_postmeta table in the database. Each entry is saved as four fields in this table:

  • meta_id: A unique ID for this specific metadata.
  • post_id: The post ID this metadata is attached to.
  • meta_key: A key used to identify the data (you’ll work with this often).
  • meta_value: The value of the metadata.

In the following screenshot, you can see how this looks in the database.

When you get right down to it, metadata is just key/value pairs saved for a specific post. This allows you to add all sorts of custom data to your posts. It is especially useful when you’re developing custom post types.

The only limit is your imagination.

Note: One thing to keep in mind is that a single meta key can have multiple meta values. This isn’t a common use, but it can be extremely powerful.

Working with post metadata

By now, you’re probably itching to build some custom meta boxes. However, to understand how custom meta boxes are useful, you must understand how to add, update, delete, and get post metadata.

I could write a book on the various ways to use metadata, but that’s not the main purpose of this tutorial. You can use the following links to learn how the post meta functions work in WordPress if you’re unfamiliar with them.

The remainder of this tutorial assumes that you’re at least familiar with how these functions work.

The setup

Before building meta boxes, you must have some ideas about what type of metadata you want to use. This tutorial will focus on building a meta box that saves a custom post CSS class, which can be used to style posts.

I’ll start you off by teaching you to develop custom code that does a few extremely simple things:

  • Adds an input box for you to add a custom post class (the meta box).
  • Saves the post class for the smashing_post_class meta key.
  • Filters the post_class hook to add your custom post class.

You can do much more complex things with meta boxes, but you need to learn the basics first.

All of the PHP code in the following sections goes into either your custom plugin file or your theme’s functions.php file.

Building a custom post meta box

Now that you know what you’re building, it’s time to start diving into some code. The first two code snippets in this section of the tutorial are mostly about setting everything up for the meta box functionality.

Since you only want your post meta box to appear on the post editor screen in the admin, you’ll use the load-post.php and load-post-new.php hooks to initialize your meta box code.

/* Fire our meta box setup function on the post editor screen. */
add_action( 'load-post.php', 'smashing_post_meta_boxes_setup' );
add_action( 'load-post-new.php', 'smashing_post_meta_boxes_setup' );

Most WordPress developers should be familiar with how hooks work, so this should not be anything new to you. The above code tells WordPress that you want to fire the smashing_post_meta_boxes_setup function on the post editor screen. The next step is to create this function.

The following code snippet will add your meta box creation function to the add_meta_boxes hook. WordPress provides this hook to add meta boxes.

/* Meta box setup function. */
function smashing_post_meta_boxes_setup() {

	/* Add meta boxes on the 'add_meta_boxes' hook. */
	add_action( 'add_meta_boxes', 'smashing_add_post_meta_boxes' );
}

Now, you can get into the fun stuff.

In the above code snippet, you added the smashing_add_post_meta_boxes() function to the add_meta_boxes hook. This function’s purpose should be to add post meta boxes.

In the next example, you’ll create a single meta box using the add_meta_box() WordPress function. However, you can add as many meta boxes as you like at this point when developing your own projects.

Before proceeding, let’s look at the add_meta_box() function:

add_meta_box( $id, $title, $callback, $page, $context = 'advanced', $priority = 'default', $callback_args = null );
  • $id: This is a unique ID assigned to your meta box. It should have a unique prefix and be valid HTML.
  • $title: The title of the meta box. Remember to internationalize this for translators.
  • $callback: The callback function that displays the output of your meta box.
  • $page: The admin page to display the meta box on. In our case, this would be the name of the post type (post, page, or a custom post type).
  • $context: Where on the page the meta box should be shown. The available options are normal, advanced, and side.
  • $priority: How high/low the meta box should be prioritized. The available options are default, core, high, and low.
  • $callback_args: An array of custom arguments you can pass to your $callback function as the second parameter.

The following code will add the post class meta box to the post editor screen.

/* Create one or more meta boxes to be displayed on the post editor screen. */
function smashing_add_post_meta_boxes() {

	add_meta_box(
		'smashing-post-class',			// Unique ID
		esc_html__( 'Post Class', 'example' ),		// Title
		'smashing_post_class_meta_box',		// Callback function
		'post',					// Admin page (or post type)
		'side',					// Context
		'default'					// Priority
	);
}

You still need to display the meta box’s HTML though. That’s where the smashing_post_class_meta_box() function comes in ($callback parameter from above).

/* Display the post meta box. */
function smashing_post_class_meta_box( $object, $box ) { ?>

	<?php wp_nonce_field( basename( __FILE__ ), 'smashing_post_class_nonce' ); ?>

	<p>
		<label for="smashing-post-class"><?php _e( "Add a custom CSS class, which will be applied to WordPress' post class.", 'example' ); ?></label>
		<br />
		<input class="widefat" type="text" name="smashing-post-class" id="smashing-post-class" value="<?php echo esc_attr( get_post_meta( $object->ID, 'smashing_post_class', true ) ); ?>" size="30" />
	</p>
<?php }

What the above function does is display the HTML output for your meta box. It displays a hidden nonce input (you can read more about nonces on the WordPress Codex). It then displays an input element for adding a custom post class as well as output the custom class if one has been input.

At this point, you should have a nice-looking meta box on your post editing screen. It should look like the following screenshot.

The meta box doesn’t actually do anything yet though. For example, it won’t save your custom post class. That’s what the next section of this tutorial is about.

Saving the meta box data

Now that you’ve learned how to create a meta box, it’s time to learn how to save post metadata.

Remember that smashing_post_meta_boxes_setup() function you created earlier? You need to modify that a bit. You’ll want to add the following code to it.

/* Save post meta on the 'save_post' hook. */
add_action( 'save_post', 'smashing_save_post_class_meta', 10, 2 );

So, that function will actually look like this:

/* Meta box setup function. */
function smashing_post_meta_boxes_setup() {

	/* Add meta boxes on the 'add_meta_boxes' hook. */
	add_action( 'add_meta_boxes', 'smashing_add_post_meta_boxes' );

	/* Save post meta on the 'save_post' hook. */
	add_action( 'save_post', 'smashing_save_post_class_meta', 10, 2 );
}

The new code you’re adding tells WordPress that you want to run a custom function on the save_post hook. This function will save, update, or delete your custom post meta.

When saving post meta, your function needs to run through a number of processes:

  • Verify the nonce set in the meta box function.
  • Check that the current user has permission to edit the post.
  • Grab the posted input value from $_POST.
  • Decide whether the meta should be added, updated, or deleted based on the posted value and the old value.

I’ve left the following function somewhat generic so that you’ll have a little flexibility when developing your own meta boxes. It is the final snippet of code that you’ll need to save the metadata for your custom post class meta box.

/* Save the meta box's post metadata. */
function smashing_save_post_class_meta( $post_id, $post ) {

	/* Verify the nonce before proceeding. */
	if ( !isset( $_POST['smashing_post_class_nonce'] ) || !wp_verify_nonce( $_POST['smashing_post_class_nonce'], basename( __FILE__ ) ) )
		return $post_id;

	/* Get the post type object. */
	$post_type = get_post_type_object( $post->post_type );

	/* Check if the current user has permission to edit the post. */
	if ( !current_user_can( $post_type->cap->edit_post, $post_id ) )
		return $post_id;

	/* Get the posted data and sanitize it for use as an HTML class. */
	$new_meta_value = ( isset( $_POST['smashing-post-class'] ) ? sanitize_html_class( $_POST['smashing-post-class'] ) : '' );

	/* Get the meta key. */
	$meta_key = 'smashing_post_class';

	/* Get the meta value of the custom field key. */
	$meta_value = get_post_meta( $post_id, $meta_key, true );

	/* If a new meta value was added and there was no previous value, add it. */
	if ( $new_meta_value && '' == $meta_value )
		add_post_meta( $post_id, $meta_key, $new_meta_value, true );

	/* If the new meta value does not match the old value, update it. */
	elseif ( $new_meta_value && $new_meta_value != $meta_value )
		update_post_meta( $post_id, $meta_key, $new_meta_value );

	/* If there is no new meta value but an old value exists, delete it. */
	elseif ( '' == $new_meta_value && $meta_value )
		delete_post_meta( $post_id, $meta_key, $meta_value );
}

At this point, you can save, update, or delete the data in the “Post Class” meta box you created from the post editor screen.

Using the metadata from meta boxes

So you have a custom post meta box that works, but you still need to do something with the metadata that it saves. That’s the point of creating meta boxes. What to do with your metadata will change from project to project, so this is not something I can answer for you. However, you will learn how to use the metadata from the meta box you’ve created.

Since you’ve been building a meta box that allows a user to input a custom post class, you’ll need to filter WordPress’ post_class hook so that the custom class appears alongside the other post classes.

Remember that get_post_meta() function from much earlier in the tutorial? You’ll need that too.

The following code adds the custom post class (if one is given) from your custom meta box.

/* Filter the post class hook with our custom post class function. */
add_filter( 'post_class', 'smashing_post_class' );

function smashing_post_class( $classes ) {

	/* Get the current post ID. */
	$post_id = get_the_ID();

	/* If we have a post ID, proceed. */
	if ( !empty( $post_id ) ) {

		/* Get the custom post class. */
		$post_class = get_post_meta( $post_id, 'smashing_post_class', true );

		/* If a post class was input, sanitize it and add it to the post class array. */
		if ( !empty( $post_class ) )
			$classes[] = sanitize_html_class( $post_class );
	}

	return $classes;
}

If you look at the source code of the page where this post is shown on the front end of the site, you’ll see something like the following screenshot.

post-class-source-code

Pretty cool, right? You can use this custom class to style posts however you want in your theme’s stylesheet.

Security

One thing you should keep in mind when saving data is security. Security is a lengthy topic and is outside the scope of this article. However, I thought it best to at least remind you to keep security in mind.

You’ve already been given a link explaining nonces earlier in this tutorial. The other resource I want to provide you with is the WordPress Codex guide on data validation. This documentation will be your best friend when learning how to save post metadata and will provide you with the tools you’ll need for keeping your plugins/themes secure.

Bonus points to anyone who can name all of the security measures used throughout this tutorial.

Create a custom meta box

Once you’ve copied, pasted, and tested the bits of pieces of code from this tutorial, I encourage you to try out something even more complex. If you really want to see how powerful meta boxes and post metadata can be, try doing something with a single meta key and multiple meta values for that key (it’s challenging).

I hope you’ve enjoyed the tutorial. Feel free to post questions about creating meta boxes in the comments.

(al)


© Justin Tadlock for Smashing Magazine, 2011.


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress