You can now view and manage the top 100 scores and usernames for all of your Game Center leaderboards. Protect your legitimate players by signing in to iTunes Connect to delete fake scores or block players that post fake scores. You can also restore scores and players within the same time period. To learn more, read the Managing Game Center Leaderboard Activity section in the iTunes Connect Developer Guide.
    
|
Animations and transitions are fairly crucial to the look and feel of modern applications, and can be a good way of indicating to a user what their interactions are doing. Indeed, the best interfaces have been clued up on this for a while now – pretty much every interaction you have with iOS involves an animation.
However animations can get convoluted really fast, especially if you have a lot of different states which require different transitions depending on which states are being entered or left. This is a problem I’ve struggled with in more complex UIs, specifically figuring out the position of elements - (we ended up using position absolute for everything, and having a huge amount of conditional code).
I’ve always wondered if there’s a better way of doing transitions and, rather than hard coding positions, delegate layout to the browser. Inspired by Keynote’s Magic Move effect, I’ve made a little jQuery library to do transitions between DOM states.
$('.containers').magicMove({
easing: 'ease',
duration: 300
},
function(){
var $el = $('<section>Third</section>');
$(this).find('.second').after($el);
}
);
The second argument to $.fn.magicMove is a callback, which gets executed in the context of whatever element you’re transitioning. Simply manipulate the DOM, hide or show elements, add or remove classes, and the changes will be animated.
You can see an example of this in action on GitHub, notice that we’re not calculating any position information–the browser is doing that for us.
The library works by appending a separate and hidden clone of the element you’re transitioning to the page. Any DOM manipulation you do is actually manipulating that clone. Then, when you’re finished, the library looks at the difference between the element’s current position, and the clone’s position, and animates between them (using CSS transitions).
]]>You’ve probably seen PSD to HTML advertisements around the web. If you type “PSD to HTML” into your favorite search engine, you’ll find lots of companies that will turn your Photoshop mockup into code. You’ll also find innumerable tutorials that demonstrate how to do it yourself.
This might leave you with the impression that every web project starts with a Photoshop mockup and, through some mystical voodoo, ends up in a web browser as beautifully crafted HTML and CSS. This is a half truth and I’d like to dispel some of misconceptions.
There’s too much variety in modern websites for there to be a one-size-fits-all approach. Photoshop can aid the design process, but it should be labeled as one of many mockup tools at your disposal, and it can even be skipped entirely in many instances. In my experience, the three most helpful tools for conceptualizing websites are wireframes, Photoshop, and code. Each has qualities suitable for certain situations.
Much like construction, changes made later in the process are much more expensive than changes made on a blueprint. Wireframes are great because you can iterate rapidly. Even if you have a clear vision in mind, it’s still a good idea to create a wireframe, because the brain has a tendency to idealize just about everything. 5-10 minutes on paper can reveal problems before they have the chance to manifest. Better yet, you might stumble upon a much stronger design in your explorations.
An example of a wireframe mockup created in Balsamiq Mockups.
Sometimes I’ll use a wireframe program like Balsamiq Mockups if I need to quickly collaborate with others, but most of my wireframes start with a pen and paper. I like to write down my goals for the site and sometimes even emotions that the person should feel when they visit. Then I start to list out all the content I want to include, such as photo galleries, videos, text blocks, and so on.
From there, I like to start blocking the content before I draw any chrome that will go around it, like headers, footers, and navigation. I draw everything using rough shapes and lines, so that I can get the composition right before I start worrying about the specific details within.
Photoshop, Illustrator, and other image editing programs are useful when some of the finer visual details have an impact on other aspects of the project. For example, let’s say you’re designing a new homepage for an established brand and your layout relies heavily on a predefined color palette. When creating a Photoshop mockup (or a high fidelity mockup as I prefer to call them), you might discover that your layout doesn’t actually work with those colors. At that point, you may be tempted to resolve the issue in software, but this is often much more time consuming than it may appear. Instead, try drawing a new layout on paper before jumping back into the computer. A tiny rough drawing created in 20 seconds could save you an hour or more of wrestling with software.
Photoshop is also useful if you’re working on a project with a reasonable budget and you need to present a nice looking design to stakeholders and clients for approval. I’m always eager to dig into code right away, but that can be an expensive waste of time if the design needs to change dramatically, so getting buy-in is helpful.
If my wireframes are pretty simple, I’ll skip Photoshop entirely. Modern frameworks like Bootstrap make it trivial to create rough layouts quickly that can be filled in with details as you go along. This is especially OK to do when you’re just adding a few new pages to an existing website that already has a well established visual language.
One of the example templates from the Bootstrap website shows how easy it is to layout complex websites using the framework.
Another reason to skip Photoshop might be if your project involves complex technology. If that’s the case, it might be more efficient to build an ugly prototype in code, then go back and refine the user experience in wireframes and Photoshop.
I get asked this question a lot. On most projects I’ll start with paper, make the jump to Photoshop for any important details, and then get into code. Someone else’s mockup methods might not work for you though, and that’s perfectly OK. The best tool for the job is the one that you’re most efficient with. If you feel like a genius in Photoshop or Illustrator and it feels more natural to you than paper, go for it. If you’re an absolute wizard in code and can manipulate CSS columns like mad, then maybe that’s for you. Websites are a highly interdisciplinary medium and there’s no one true path to creating them.
If you have any crafty or unusual mockup tips you’d like to share in the comments, I’d love to hear them!
The post There’s more than one way to mockup a website. appeared first on Treehouse Blog.
]]>|
|