Luke Wroblewski doesn’t disappoint in this short guide on Mobile First for designers. Reading through this guide offers a wealth of advice, every second sentence it felt like another simple statement resonating within me. Here are just a few highlights (really) I particularly enjoyed, but for a few quid go and get the whole book:

Growth

• Websites and applications should be designed and built for mobile first.
• Smartphones were boldly predicted to out-ship the combined global market of laptop, desktop, and notebook computers in 2012. They did so in the last quarter of 2010 – two years earlier than predicted. 
• … even if you can create native applications for each platform, the cost of maintaining them can quickly make it prohibitive.
• The combination of mobile and desktop experiences results in more engaged users across both sets of devices.

Constraints

• Screens are small, networks are unreliable, and people can find themselves in all kinds of situations when they pull out their mobile device.
• … design is the process of gradually applying constraints until an elegant solution remains.
• … 80% of the screen space from the desktop was missing.
• … Thinking “one eyeball, one thumb” forces you to simplify mobile designs …

Capabilities

• … mobile capabilities allow you to do: reinvent ways to meet people’s needs using exciting new tools …

Organisation

• Aligning with mobile behaviors also naturally aligns your website with real-world needs.
• … content takes precedence over navigation on mobile.
• … allowing people to explore and pivot to relevant content doesn’t have to mean piles of navigation bars that bury content.
• If you need a fixed menu, better to fix it to the top, as Twitter has done.
• … fingers are imprecise pointing instruments… [ isn't that obvious?, many examples I see say not so ] bigger [not downsized] touch targets are essential.
• Destructive actions like cancel or delete can be placed outside people’s comfort zone.
• Consistency in interaction approaches and gestures more than diversity. See Luke’s detailed guide here: Common Gesture Reference.
• We are in a transition phase from GUIs to NUIs (Natural User Interfaces).
• Develop with progressive enhancement in mind

Refer to Apples guidelines for target sizes and much much more

Inputs

• Take advantage of input types, attributes, and masks to make mobile input easier.
• Select menus are pretty tap-intensive: tap the menu once to open it, swipe the list that shows up to find the answer you want to select, tap it, and then tap down or close to go back to the form.
• HTML5 input types can help people accurately answer questions that require a specific format.
• … take the height of virtual keyboards into account …
• Actively encourage input and allow people to contribute and create using their mobile devices.

Layout

• … the meta viewport tag is really useful for designing mobile web experiences.
• Forget pixels and instead concentrate on points, for example on all iPhones this is consistent at 320×480, only the pixel density changes.
• Render rounded borders & graduated backgrounds using CSS3 but not to many or performance will be compromised.
• Flexible layouts which expand and adjust to the available width of the device are essential.
• Use break points to provide differing layout rules at significantly different device criteria. See more in Responsive Web Design.
• Consider the differences between connected TVs, desktops/laptops, tablets, smartphones, and feature phones.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Firstly you need to understand how being more standards conformant may affect your application. If you have been avoiding activerecord for perhaps performance reasons in some queries check to make sure they are going to still work the way you expect.

My checklist includes:

• Text comparisons are now lowercase
• Quotes follow the SQL standard and using single quotes not double as mysql accepts
• tSearch2 as an alternative to solr and sphinx and its built in
• Tests
• The knowledge that my app doesn’t use anything non standard so should just work

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

rake/rdoctask is deprecated. Use rdoc/task instead (in RDoc 2.4.2+)

then open up your rakefile.rb and change

require 'rake/rdoctask'

to look like this:

require 'rdoc/task'

and remember to add the following to your Gemfile

group :development do
gem 'rdoc'

end

You may need to run the following on the command line to freshen your gems

sudo bundle install

Related posts:

1. Quick Tip: sudo: rake: command not found To resolve this issue which for me applies to Ubuntu...

Related posts brought to you by Yet Another Related Posts Plugin.

Fix: Easy I can add an array of arrays to my model file and them pull them through to the view. In each sub-array the first element in the name displayed, the second is that submitted with the request.

Example: In the model for my bookings I add booking_status

class Booking < ActiveRecord::Base

  BOOKING_STATUS = [
    ['booked', 'booked'],
    ['request', 'request'],
    ['pending', 'pending'],
    ['approved', 'approved'],
    ['not-approved', 'not_approved'],
    ['other', 'other'] ]

end

In the view I can then include a selection tag which uses each of these items

<%= f.select :status, Booking::BOOKING_STATUS %>

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Yes I know I prototyping, yes I know I’m going to through it away at the end of the day but still there is no need for not making effective use of partials in forms.

Partials within forms makes sure functionality is rapidly updated in both the new and edit actions.

So typically I like to convert:

<h1>Editing booking</h1>

<% form_for(@booking) do |f| %>
  <%= f.error_messages %>

  <p>
    <%= f.label :event_id %><br />
    <%= f.text_field :event_id %>
  </p>
  <p>
    <%= f.label :user_id %><br />
    <%= f.text_field :user_id %>
  </p>
  <p>
    <%= f.label :status %><br />
    <%= f.text_field :status %>
  </p>
  <p>
    <%= f.submit 'Update' %>
  </p>
<% end %>

to something which makes much more sense like:

<h1>Editing booking</h1>

<% form_for(@booking) do |f| %>
  <%= render :partial => 'form', :locals => { :f => f } %>
  <p>
    <%= f.submit 'Update' %>
  </p>
<% end %>

I’d encourage you to do the same and see how it saves you one more piece of hassle. And of course if your using text mate remember ctrl+shift+H will create the partial for you.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

NameVirtualHost *:80

<VirtualHost *:80>

RailsEnv beta

ServerName my-app.redjamjar.net

DocumentRoot /home/rails/beta/my-app/current/public

<Directory “/home/rails/beta/my-app/current/public”>

allow from all

AllowOverride All

</Directory>

</VirtualHost>

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Action Plan:

1. Identify the unknowns
   How? Start simply with broad questions. Don’t be too quick to get into the detail as this will be the natural tendency. At this stage understand nothing about the detail but fully comprehending the end user environment or capabilities will give you a greater barometer for detecting where the unknowns are essential or not.
2. Questions everything, assume nothing
   I’ve tripped over this many times, combined with one this is probably the largest probably when scoping, initiating or specify an integration piece of work. I find Excel is my friend in this situation, I can capture questions and responses as the knowledge flows
3. Seek documentation but don’t rely on it.
   Documentation in what ever form is usually well intentioned, but out of date, inaccurate or just plain wrong. Typically the documentation will look grand ‘Technical Specification for X.Y.Z version 1.2′ however what tends to happen is that was written at the outset before a line of code had been written – ask yourself when you last went back and updated a specification at the end of project, yet you want to make key integration decisions based on it?
4. Get a setup of the system as close as possible to the real environment for use during development, verification testing and UAT
5. Commit, integrate and test regularly. Really if your not doing this forget it
6. Use real data not ‘lorem ipsum’ or ‘test account 1′
   Demand this especially if you have translation or localisation considerations to consider.
7. Allow your/encourage your client to come and inspect your work – they may see things your developer mind over looked.
   Coming from a developer mind I’m always surprised how easy it is to be lulled by our perspective on systems.
8. Testing
   Even with all the automated testing, eyeballs and code reviews I’m still amazed by how often I come across developers who see it as acceptable to ship code from their development computer to a production environment without any testing.

Have I overlooked anything you find works best for you? Let me have your comments and I’ll add them in.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

> scp 

usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2

So how does this matter for me well if you wanted to move a file from a server called Mojo.com to a server called Louis.com you’d enter

> scp file.txt my_login_name@louis.com:remote_directory

or if I want to copy a folder:

> scp -r my_login_name@louis.com:remote_directory my_files

Hope this helps.

By the way for those on Windows Penguinet has scp built in with a nice looking file browser/selection UI.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

<% form_tag :controller => '/' do %>
				<%= t(:'txt.language') %> <%= select_tag("locale", options_for_select(LOCALES_AVAILABLE, I18n.locale), { :index => nil,  nchange => 'this.form.submit()'}) %>
			<% end %>

Our client reported that on a signup page where they choose an alternative language it got redirected and they could never reach the page in their native language.

How can this happen you might ask?

Well the request includes some values within the url which are used as a key. Only if the key is valid is the controller allowed to complete the request. The issue is the combining of maintaining the key and switching the language.

As it happens its a very simple fix and was pointed out to me by Juliana.

<% form_tag :controller => request.request_uri do %>
				<%= t(:'txt.language') %> <%= select_tag("locale", options_for_select(LOCALES_AVAILABLE, I18n.locale), { :index => nil,  nchange => 'this.form.submit()'}) %>
			<% end %>

In this fixed second example the alteration for the controller has been updated to direct the language selector to the controller of the current page. The documentation for this suggests that its broken on IIS (really should you be even trying to use this?) in fact I found that the source has had a significant amount of work go into it to work around the issue and even make it work on that webserver. Its a great little solution to ensure that the reloaded page is returned to the user in the state it was with the addition of the correct language.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Try it for yourself over at http://www.themaninblue.com/experiment/JS-909/

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.