With the year nearly behind us, the designers at Numiko have huddled together to bring Christmas around early. Their gift to you is an indispensable guide to Photoshop containing priceless tips you’ll soon be unable to live without!

Stay smart with Smart Objects
One of the most common issues we face within web design today is the duplication of modular content. Up until the release of Adobe Photoshop CS2, designers had to make multiple copies of individual page assets if they needed to appear on different templates.

While you could argue there is nothing wrong with this type of workflow, problems begin to arise when amends fly into your inbox. Whether it was a change in colour, typography or even the shape and size of a module; designers adopting this workflow would have to ensure they carefully amended each duplicated asset. Something far from ideal, given there could be countless instances of this module spanning multiple pages.

More recent versions of Photoshop take away this troublesome task of repeating the same change(s) multiple times with the introduction of smart objects.

Smart objects are effectively smaller Photoshop documents nested within your main Photoshop document. A selection of layers or a folder within your existing document can be converted into a smart object by right clicking the desired layers and selecting ‘Convert to smart object’. Once you have a smart object, double clicking on the layer’s icon will open an additional window which contains the nested file’s contents. Upon making any changes to this new window and saving, the nested document will then update itself in your main Photoshop document.

So how does this differ from our problem presented above? Upon saving, the updated contents of any smart object will then update any duplicated instances of it too. This means you could have, for example, five copies of a footer duplicated over multiple templates, all of which will only need to be edited and updated once.

Control your Layer Comps
As time goes on, the structure of your Photoshop documents will begin to grow more complex. With a plethora of page templates to consider, you better hope you have an organised method of keeping each one easily accessible and under control.

Most designers today tend to arrange their layers into carefully labelled folders, calling upon each one when required by changing its visibility. This, however, is a rather inefficient way of working when Layer Comps are just around the corner.

Layer Comps are the solution to getting every single layer related to a single page template or design visible with a single click. With Photoshop open and your latest design in front of you, heading to Window > Layer Comps is your first step. Next up, clicking the new Layer Comp icon at the bottom of this panel will prompt you to name your currently visible template. This will then make a note of which layers are currently visible (and invisible) and make an entry in the Layer Comps panel for later use.

From here just a single click on any empty square to the left of a template’s name in the Layer Comps window will hide any unrelated layers and make anything belonging to that template visible. Gone are the days of hiding and showing the layers manually – simply create a Layer Comp for each page you design and you’ll be laughing. Just remember you’ll need to click the update button with your Layer Comp selected every time you’re ready to commit your amends to it.

This, however, is not where Layer Comps end.

There is one more incredibly handy function. Deep within File > Scripts lies the ultimate solution to preparing your work for approval and client send off – Layer Comps to files. This script will simply run through your page templates that have been added to the Layer Comps panel and export them to your hard drive. The output will be in a file format of your choice, with the filename of each template inherited from each Layer Comp.

Organisation is the key!

Be Non Destructive
With tools such as the Paint bucket, Eraser and the Smudge cursor, Photoshop was intended to be a messy affair. While these elements of destruction do offer a great flexibility to creating pixel perfect assets, working in a non-destructive workflow has its advantages too.

To define non-destructive in Photoshop terms: it’s the act of using any supplied assets or imagery without editing them directly. There are obviously times where you’ll need to retouch a photograph by adding sombreros to a row of gleeful cats, but all other editing should be done without touching the original file if possible.

Take for example a client supplied image that needs to fit into a homepage carousel. Chances are the image will be too tall, too wide or even both. This, however, is a good thing that can work to your advantage.

Simply create a new solid colour layer or shape layer below, one which is exact the size you’d like your supplied asset to be. From here, right click the asset’s layer and select Create clipping mask. This will make the asset only show through the available pixels of the layer below. This allows you to freely move around the image in any way you wish within the designated space, without needing to cut off (and destruct) any unwanted imagery.

If you’d prefer to keep everything within one layer though, take a look at alpha channels. They offer exactly the same functionality too.

Why’s this a good thing then? Well should any amends fly through the door asking for a previously hidden area of the asset to be made visible, that’s something you can do without needing to open the original file again. It’s still intact within your document and awaiting changes.

You could then take this tip a step further by reading on…

Keep key graphical elements in Smart Objects
When designing a website in Photoshop, every single element that is associated to that design – whether it is client logos, affiliate branding or even imagery – should be present in its original form. This grants developers who are coding your design or clients who require Photoshop documents to be supplied, access to everything they need within one file.

To achieve this, the best practice is to import any asset at its full size into your document and then convert it to a Smart Object before use. Should anyone need to get hold of this asset, it can then easily be found in the same place all your other assets are: within the Photoshop document.

Aside from being more organised and prepared for handovers, there is another advantage to being smart. Take this request for example: “make our logo twice as large”.

A common request to face, but a fatal one should you have misplaced the original asset. This is nothing to worry about when Smart Objects are in place. As all the original data from an individual asset still exists within a Smart Object, you can transform away, whilst maintain quality.

Save and save often!
Sadly, the last but most important Photoshop tip of all is the one we all learn a little too late. The Adobe-software-crash-devil which drags your hard work down to the depths of unrecoverable computer hell rears his ugly side all too often. The more infuriating aspect to Photoshop crashing (frequently) is knowing full well that Save was just a few clicks away and available all along – something you didn’t utilise in time.

To keep the crashes at bay, we’d very much recommend saving into new files each time round. For example, the brand new template featuring that sparkly and clean header you’ve just spent a few hours on, save that as Design-v2.psd instead of overwriting. By working in multiple files, you have the ability to travel back in time should you need to revisit an earlier version of your creation for whatever reason.

Whilst we’d like to consider ourselves Photoshop gurus (at least our portfolio suggests so!), there’s always room for improvement. Feel free to share your very own Photoshop tips in the comments box.

We love Drupal and we needed content management. The question was – how can we serve potentially thousands of pages a second? The answer was – not with Drupal! We needed to move beyond standard Drupal caching, and beyond even the excellent Boost module. Instead, our Drupal module publishes pages to Amazon S3 and this acts as the origin for a heavily CDN-cached site that can be edited like any other content managed site.

By serving static pages and not touching Drupal at all we removed a lot of potential problems – complex server setup, strange database errors, the White Screen of Death – that are possible when a complex, database-heavy site comes under severe strain.

Our Caching Module

Our module takes inspiration from Boost by saving a static copy of a page during the exit hook. But where we differ is that this happens on a “crawl” of the site that is itself initiated in the exit hook, triggered by a flag set by a node delete, insert or update hook. So the basic flow is:

• content editor saves a node
• in hook_exit() we start the crawl – requests to the current node and any related pages are made using drupal_http_request() with an added querystring parameter
• now in the separate request, the querystring parameter is detected and during hook_exit() we save the contents of the output buffer to S3

This separate request allows us the view the page once it’s completely built (rather than during the request that created it) and to get its content as an anonymous user.

A page doesn’t exist in isolation so related pages need to be kept up to date. Fortunately, on this site related pages meant taxonomy View lead pages for media nodes and not much else. This meant we could hardcode the logic for this on a case-by-case basis. For a more complex site many more pages (or the whole site) may need to be republished when one page changes.

We also added a “Publish whole site” option that crawled all nodes of a certain type and various other lead pages that were not nodes – useful if site-wide changes were made or if anything went wrong with the publish process.

Indeed, error handling paramount and was important to allow fast diagnosis of any problems on the night. Thankfully there were no major problems, but detailed logging meant I could monitor usage by content editors and be reassured that everything was working. In unpredictable situations like this – high traffic, contacting external systems, live TV broadcast! – log as much relevant data as you can (while keeping it manageable – there’s no point having an overwhelming amount of data that’s impossible to understand quickly).

S3

At first I thought it would be a good idea to mount S3 locally so that I could transparently use normal filesystem functions to deal with the static files. Turns out that due to the way S3 deals with directories (or doesn’t, it doesn’t really have a concept of directories) this was unreliable. The official Amazon S3 class is really nice to use anyway:

    $response = $s3->create_object(
      $bucket,
      $filename,
      array(
        "acl"=>AmazonS3::ACL_PUBLIC,
        "body"=>$data,
        "contentType"=>"text/html",
        "headers"=>array(
          "Cache-Control"=>"public, max-age=" . $html_cache_control
        )
      )
    );

This saves the $data to S3 as the correct content type, setting permissions and the cache header to work with the CDN. We made cache max-age times for various objects configurable through the Drupal interface for easy tweaking.

Assets

We used the Drupal S3 module so that CMS-uploaded assets were sent to S3 as well. We’ve used this in the past and it transparently deals with this for us.

One image-related difficulty was that some generated images hadn’t been saved to S3 by the time the caching module saved the HTML, resulting in references to images on the Drupal server. We didn’t want this under any circumstances so at first I stopped any page with a local image URL being published and returned an error. Later, it became obvious that the best solution was to brute-force replace all offending paths in the HTML with the S3 one – eventually the image would be generated.

Frequent Updated Content

Some of content needed to be more dynamic – the home page live feed and the total amount raised on the right-hand column. For these we had a separate publishing mechanism. Data was published to JSON files (again to S3) when content was updated and these were loaded regularly and interpreted by the front end. In this way key content could be kept fresh while the bulk of the site was cached for longer periods.

On the Night

So with S3 and Akamai taking care of the end-user traffic, Drupal was left untouched by the general public, removing most of the worries that come when a site is released into the wild for the first time. We think taking the principle of the Boost module one step further and publishing on-demand to an external server gives us the right trade-off between performance and flexibility for a site like this, and didn’t require a huge investment in setup time.

  $rows = db_query("SELECT * FROM field_collection_item;")->fetchAll();

  $export = $all_ids = array();

  foreach($rows as $row){
    $all_ids[] = $row->item_id;
  }

  $items = entity_load("field_collection_item", $all_ids);

  foreach($items as $item){
    $export[] = $item->export();
  }

This is thanks to the field collection entity’s controller class EntityAPIController implementing a handy export() method.

Then to import a field collection exported to $export_str:

  $con = new EntityAPIController("field_collection_item");
  $entity = $con->import($export_str);
  $con->save($entity);

The exported JSON contains an item_id. If you unset this the collection will be saved with a new item_id (generally a good idea) but there are some circumstances where you might want to import the field collection with its original ID (this will maintain the references to the field collections host but be careful!)

Importing and exporting is never fun with Drupal but the above code should help with any tasks (in my case populating a site with test data needed by Selenium tests) that require field collections to be moved between sites.

We’ve recently been developing a few games and activities for interactive whiteboards, and found that they have a few kinks that it can be hard to keep track of during the design and dev process. So I thought I’d try and put down everything we’ve learned in one place.

Avoid putting critical controls in the top third of the screen. The majority of your audience is kids – kids who are still growing, and often aren’t tall enough to reach up to the top of a whiteboard. It’s also important for accessibility for people in wheelchairs who might not be able to reach as high as others. Schools install their whiteboards at different heights too, so keep any essential controls low on the screen if you want them to be accessible.

Controls that are used by the teacher, like mute, are fine to go nearer the top as the kids don’t need to be able to reach them – in fact, some controls are probably best kept out of the reach of meddling kids anyway to avoid accidental quitting or restarting.

Lots more whiteboard development tips after the jump…

Keep text over a certain size if you want it to be read by a class. There are loads of different modes of use to consider when you’re designing for education: solo use at a computer, groups round a laptop, child using a whiteboard, teacher teaching from a whiteboard…

Important text needs to be large enough so it can be read by children in a classroom. What needs to be legible depends on the content and the lesson, so it’s difficult to lay down hard and fast rules, but you should be able to identify key information.

Conversely (depending on your users) too much over-large text can make content for older children feel too kiddy, which will turn them off it quicker than you can write out “I will research my audience” a hundred times.

Personally, I’ve always thought that lessons where the teacher just read stuff off a screen were deathly dull, so maybe think about how you can help the teacher present information in a more interesting way than a big wall of text. That’s just my opinion, though!

Keep colour contrast high. Whiteboard content needs to work in all manner of classrooms, which will probably vary from dank dungeons to bright-as-the-sun computer labs. There are colour contrast checker tools that make this easy, if time-consuming. Plan for it, and do it while you’re designing, because there’s nothing more annoying than having to go back through all your designs and change everything, again.

Consider including high-visibility modes to help teachers who have crappy low contrast projectors or sunny windows with no curtains.

Don’t make people scroll. Keeping everything on screen at once will make thing easier for teachers, because scrolling means locating the scroll bar and dragging your finger down the board, rather than a quick click of the mouse. If you really do need to scroll, think about how you can minimise the pain – for example, “proper” touchscreen interfaces let you scroll by dragging any point on the screen.

The option to go full-screen is good. It helps teachers focus the class on the content rather than what’s in their bookmarks or any other screen clutter.

An interactive whiteboard is basically a big touchscreen, and it’s worth bearing that in mind when you’re planning functionality. A lot of traditional web HTML content is fine, but for more interactive elements it’s easy to trip yourself up by designing for a single user with a mouse and keyboard. If you’ve got guidelines for designing for iPad then take a look at those because they’re probably relevant – just don’t go too far the other way and neglect the needs of your desktop users.

The touchscreen interface has some important implications:

There’s no mouse cursor. Well, there kind of is, but not in the way it works on a desktop. When you put your finger on the whiteboard the cursor will jump to that point and simulate a mouse button press. Release your finger and you’ll get a mouse button release. Otherwise the cursor will just sit in the same spot until you interact.

You can’t hover over things on a whiteboard. This means no mouse over events, so no interactions on rollover. Don’t rely on rollover popups to deliver information, because they ain’t happening.

When you’ve pressed you can drag the cursor around, which will probably display rollovers (depending on how you’ve coded them) but this behaviour seems inconsistent across different brands and is not obvious to the user.

Similarly, don’t rely on being able to tell when the user has moved their mouse out of something, or even “moved the mouse” at all. It seems obvious, but those events are so common in desktop apps that it’s easy to forget about them. On an interactive whiteboard, there is no mouse. And no-one can hear you scream because your app relies on rollovers and now you have to change it all.

Beware press and hold. On some models of IWB (but not all) pressing and holding in one place for a few seconds will be interpreted as a right-mouse-button click. Maybe that’s what you want – but it probably isn’t.

Fingers are less precise than a mouse cursor (and more chunky). When you’re used to the sensitive, high-spec interface of an iPhone it’s not as obvious, but for uncoordinated kids using a crappy old unbranded whiteboard it can be an issue. Make sure that hit areas are big enough for fingers and well-defined, with as little overlap or confusion as possible. I know that’s good advice generally, but it goes double for a whiteboard.

The minimum suggested hit area for mobile is 50px (I imagine this varies by device etc) – there’s no standard for whiteboards as far as I can tell, but just bear this in mind.

The user’s hand and arm will likely block some of their view of the screen when they reach to interact; showing critical information right below where someone’s interacting will require them to bend their arm or head in an uncomfortable way to spot the cue – if they don’t miss just it altogether. Some whiteboards use overhead projectors which can make the problem even worse by making your entire body cast a shadow.

Some whiteboards will have whiteboard pens, which will give a more precise interaction area and additional controls, but as with most things here it’s best to not assume that classrooms will have the latest, shiniest equipment. Whiteboard pens sometimes contain widgets that make the board interpret them differently as well, which may cause unexpected behaviour.

It takes more effort to move around a whiteboard. When you’re using a mouse, moving to the other side of the screen is a mere flick of the wrist. But on a whiteboard, dragging something from the left to the right involves keeping your finger firmly on the screen and moving your arm (and probably your whole body) a metre or so.

Whiteboards can be very unresponsive, so if your activity includes fast or precise movement bear that in mind. Some brands are pretty bad at detecting taps occurring close together in time (eg double clicking).

Testing is difficult. Different brands of whiteboard offer hugely varied levels of contrast, responsiveness, types of interaction and all kinds of other totally non-obvious stuff. It’s relatively common to encounter those most premature-hair-greying of bugs: something to do with a specific piece of hardware that you don’t have access to.

There’s not much you can do about this except be aware of it and try to build resilient, flexible apps that can be easily tweaked if it looks like a specific thing is causing a problem.

We had trouble when a client’s whiteboard showed weird text distortion artefacts and serious unresponsiveness when ours was completely fine. This mysteriously fixed itself after a day or so, which was just as well because we had no idea what was causing it and no way of fixing it.

The people who are testing your content are probably not teachers. Unless they are, in which case it’s fine. But it’s possible that some errors are coming up because the person doing the testing is unfamiliar with interactive whiteboards. This sounds like a bit of a cop-out, but all child interaction with the board will be teacher-moderated, or at least guided, and most teachers will have experience with boards in general (and specifically the quirks of their board).

It’s not something to rely on, but it is worth bearing in mind when you’re bug-hunting. For example: almost all teachers use fingers to interact and pens to write with on the board – that’s how they’re designed to work. But our testers were using the pens to interact with all the content, which was throwing up some weird results.

Celebrate the teacher! This ties into the “too much crap on screen is boring” bit. You may or may not actually get a say in what the content is that you’re creating, or how it works, but if you do then try to make something that lets the teacher teach, rather than just be a drone who exists only to click through a slideshow.

Use interactivity, audio, quizzes and reveals to make something that can help the teacher inspire their class. There’s a wealth of information online about what makes good teaching content, so check that out, look at presentation skills and information and talk to teachers. The teachers will appreciate it, and so will their pupils!

$field = array(
    "field_name"=>;"field_field_name",
    "label"=>"Field label",
    "type"=>"node_reference",
    "settings"=>array(
      "referenceable_types"=>array(
        "gallery_image"=>"gallery_image"
      ),
    ),
    "cardinality"=>"-1"
  );

  field_create_field($field);

  $instance = array(
    "field_name"=>"field_field_name",
    "label"=>"Field label",
    "type"=>"node_reference",
    "widget"=>array(
      "type"=>"options_select"
    ),
  );

  $instance["entity_type"] = "node";

  foreach(array("type1", "type2", "type3") as $type){
    $instance["bundle"] = $type;  
    field_create_instance($instance);
  }

“gallery_image” is the machine name of the type that will be referenced by the field – put as many in here as you need (yes, the format really is “machine_name”=>”machine_name”). “cardinality” is the number of references in the field, -1 being unlimited. In the example, the field will be added to 3 types – type1, type2 and type3.

#main #content #inner h3

this was causing huge problems when any external mark-up was dropped into the page. The generic styles were already so specfiic that they were over-riding most other CSS styles. Before you know it you needed to tag everything with:

#main #content #inner #something .get .my .point

to make the styles to cascade properly.

It’s worth remembering that although

#main #content a {color:black}

looks fairly innocuous but when you later to need to change the style of an anchor tag you’ll be stuck needed to add a lot of specification and worse external mark-up, unaware of your overly described selectors will end up being overridden. Before you know it your rules are flowing off the page and every new change requires a train of selectors, tags and classes.

It’s worth then noting how CSS decided what styles to use – Other people have done a better job than I would manage so I’ll just point you towards a few articles that cleverly explain the problem:

http://iamacamera.org/default.aspx?id=95

http://coding.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/

Enjoy!

The Framework Myth says you don’t need an internal omnipotent framework. I agree – over the years we have built up a small collection of re-usable code, based on experience of actually needing that code in our situation. Coders love to code, and I have to admit feeling a thrill at writing my own APIs but “you are probably not getting paid to fulfill your dreams, you are getting paid to write the damn code.”

Reusable Code is Bad is a headline in the tradition of hyperbolic blog post headlines, but “never build something to be reused until you actually have two systems that actually need to reuse it right now.” is something that makes sense to me.

Crucially, I think, everybody’s situation is different so you always have to judge for yourself. But as I look back over a decade of projects, how much unused reusable code did I write? How many times did I sweat over whether to take the time to “add another layer of abstraction and logical branching to my function” and how many times was I wrong when I decided to? Less and less as experience has taught me not to.

You should understand the principles of code reuse, no doubt, but learn to use your own judgement in your current situation. As with all advice, just because Google/Facebook/37 Signals/some-guy-with-a-blog says it’s a good idea, doesn’t mean it is for you.

db_query

No need to mess about with fetching rows any more, db_query() returns a Traversable object which can be foreach-ed. Also, placeholders no longer need quote marks. (The Numiko API has taken care of these conveniences for a while now, glad they are no longer needed).

Comments

It’s now easy to output comments separately, meaning they can be placed anywhere on a node. No more hacking it.

Profiling

The Devel module now integrates the XHProf Profiler, which looks useful for finding bottlenecks in code.

Checkboxes

Now simple and logical to create on types. Previously I always had to refer to how I did it the last time.

More Granular Permissions

Which is good, and they are more logical. It will require a bit more thought from developers when defining roles e.g. all of the following permissions would generally be required as a base for a site editor: “Use the administration toolbar”, “View the administration theme”, “Use the administration pages and help”, “Access the administrative overlay”, “View the administrative dashboard, “Access the content overview page”.

Thankfully the infamous “Administer content” permission has been tamed.

Content List Page

This page now has sortable columns, and an “Updated” column, instantly making content easier to find and identify. AJAX auto-complete filtering here would make it complete.

Facebook seems to read this from the canvas URL now instead – so try setting that to be the same as your Site URL.

Incidentally, I only had this problem when working from localhost – with sites on the public Internet, setting the site URL only worked fine.

SELECT count(uid), 

  MONTH(FROM_UNIXTIME(created)) as bmonth, 

  YEAR(FROM_UNIXTIME(created)) as byear 

FROM users 

GROUP BY bmonth, byear 

ORDER BY byear, bmonth;