technology from back to front

Archive for January, 2014

UX design in Agile projects

We’ve been making a habit of collaboration with partners for what seems like forever, so why is it that we find it hard to get the formula right with front-end designers? Are we a particularly fussy bunch, orĀ is there something more systematic going on?

Recently we’ve been working with the Agile Research Network who were interested in researching this area and its been useful to have someone external observing projects and documenting conclusions.

The Agile mantra of avoiding BDUF (Big Design Up Front), fails to provide specific guidance over what constitutes “Enough DUF” and guidelines are helpful. Some of what was highlighted was obvious, some less so, here’s a sample:

  • Design prototypes, or demonstrators that look too perfect are dangerous
  • Pixel-perfect UX designs will increase resistance to change
  • Prioritisation and de-scoping renders pixel-perfect designs unnecessary
  • Good UX, like good technical design should be modular
  • Some issues with the design will only be found once you start implementing
  • Get UX and technical designers collaborating on each others’ decisions
  • Consider using an analyst to work closely with both teams documenting requirements conclusions from their work

An initial white paper from the ARN was presented at the Agile Conference in October 2013, a more in depth research paper is under preparation as the moment.

 

 

 

by
mike
on
15/01/14

Typesetr at the Frankfurt Book Fair

LShift and its partners from the Leuphana Inkubator (University of Hamburg) presented Typesetr(™) to a packed session at this year’s Frankfurt Bookfair during the “The Future of Higher Education and Academic Publishing” seminar.

Typesetr had just undergone a complete UI refresh and integration with the Zotero citation and bibliography service before the show and so attracted a great deal of interest. Typesetr is going to be used as the semantic editing and document transform platform for the EU’s principal research initiative for Open Access publishing infrastructure over the next three years.

The academic version of Typesetr shown to conference delegates enables students, researchers and academic departments to collaboratively create, edit, transform and enrich complex documents whether they be intended for book, journal, monograph or digital distribution formats. An intermediate representation of a highly structured document is maintained such that switching between different output targets doesn’t affect the original’s structure or metadata or compromise the design and specification of the desired output format.

Along with Zotero integration, support for some of the world’s leading Open Access academic publishers is next up for Typesetr’s development road map. If you’d like more information, or to join the Typesetr closed beta program then contact us

by
sophie
on
14/01/14

Grunt uglify file specs

I struggled a bit finding relevant examples of Gruntfile configuration for Uglify, so having solved a few specific problems myself, here’s what I came up with.

This is just a snippet from the whole Gruntfile of course, and contains half-decent comments already, though I’ll provide some extra explanations below to point out the most interesting bits.

// Variables used internally within this config.
conf: {
  app: 'app',
  dist: 'dist',
  // Just our own custom scripts.
  script_files: ['scripts/*.js'],
  // All scripts that should be minified into final result.
  // Ordering is important as it determines order in the minified output and hence load order at runtime.
  // We don't include jquery (though we could) as it's better to get it from Google where possible.
  minify_js_files: [
      'scripts/vendor/modernizr/modernizr.custom.js',
      '<%= conf.script_files %>',
      'scripts/polyfills/**/*.js']
},

uglify: {
  options: {
    banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n',
    sourceMap: '<%= conf.dist %>/scripts/source.map.js',
    sourceMapRoot: '/scripts',
    sourceMappingURL: '/scripts/source.map.js',
    sourceMapPrefix: 2
  },
  // For dev, effectively just concatenate all the JS into one file but perform no real minification.
  // This means that the HTML is the same for dev and prod (it just loads the single .js file) but
  // debugging in the browser works properly in the dev environment. It should work even when fully
  // minified, given the source maps, but practice shows that it doesn't.
  dev: {
    options: {
      report: false,
      mangle: false,
      compress: false,
      beautify: true
    },
    files: [{
      expand: true,
      cwd: '<%= conf.app %>',
      src: '<%= conf.minify_js_files %>',
      dest: '<%= conf.dist %>/scripts/main.min.js',
      // Because we want all individual sources to go into a single dest file, we need to use this
      // rename function to ensure all srcs get the same dest, otherwise each would get a separate
      // dest created by concatenting the src path onto dest path.
      rename: function(dest, src) { return dest; }
    }]
  },
  prod: {
    options: {
      banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n',
      report: 'min',
      mangle: true,
      compress: true
    },
    files: '<%= uglify.dev.files %>'
  }
},

Use of a rename function for configuring file srcs and dests

I was really struggling to come up with src/dest configuration for Uglify that pushed all of my source files into a single minified dest file. To be fair, this is trivially easy in the common case, as you can simply use files: { ‘dest_path’: ['file_1', 'file2'] }.

However I have my list of source files in <%= conf.minify_js_files %> and the paths therein do not include the root app/ directory, because this works out for the best in various other Grunt tasks (not shown) where I use cwd in the files block to supply that root dir. Unfortunately, without my custom rename function, a separate dest is calculated for each src file, by concatenating the src path with the dest, so instead of one minified JS file we get lots of individual files sprayed over all sorts of unintended locations. The trivial rename function I’ve used overrides those calculated dest locations to our originally intended single dest. Where different srcs have the same dest, the grunt-contrib-uglify plugin has the good sense to assume you want to merge their output. And hence we get the result we want. To be clear, this is only complicated because I want to use cwd in the file config rather than using the simpler approach.

Re-using files blocks in multiple places

You can share common options amongst multiple targets by putting them at the top level of the task and overriding/extending as required in the specific targets. However you can’t do this when specifying files. In my case I want to specify the same files for both dev and prod Uglify targets, so I specify them in full for dev then use Grunt’s templating facility to refer to them from prod with files: ‘<%= uglify.dev.files %>’.

Theoretically I could have put the definition in the conf block at the top, but it’s specific to Uglify and only used there so I prefer it to be local to the Uglify task. It seems obvious now that I can refer back to it like this, but at the time I struggled to see how to achieve it. I think I had a blind spot for the generic nature of the templating mechanism, having only used it in a rigid way for config previously, and still being very new to Gruntfiles.

Uglify may break JS debugging

I found that my minified JS files could not be successfully debugged in any browsers. I could see the original un-minified code thanks to the source maps and I could set breakpoints, but they usually wouldn’t trigger, or if I did break (e.g. with JS ‘debugger’ command in my code) it was impossible to get variable values. All very frustrating.

Whilst I’m developing I use Grunt’s watch task to serve my files and to auto-process modifications on the fly, so in that mode I turn off all the actual minification features of Uglify and effectively just concatenate the files together into one. Because it’s still the same single file with the same name as in production, I can use identical static HTML to include my JS script. The source maps are still there and allow me to see the individual files in the browser debugger.

by
Sam Carr
on
08/01/14

Search

Categories

You are currently browsing the LShift Ltd. blog archives for January, 2014.

Feeds

Archives

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us