Disrupting Your Web Development Workflow

I had a chance to speak at the Iowa Javascript meetup about Web Development Workflow tools.

There are three things which have really made me reconsider and revise the process by which I organize and deploy code to servers:

• The need to make ideas and concepts available for consumption as quickly as possible.
  I work in a lot of collaborative areas, so it is important for me to say “what about this?” in an electronic medium where people can play with it, try it out, see how it feels. So I want to maximize the time I spend building awesome new stuff, and minimize, automate, or delagate some of the operations type considerations.
• Cloud and mobile.
  The days of deploying a site to one known server, to be viewed on a couple known desktop browsers are gone. You need to be able to scale up your app very quickly, and that’s much easier if you plan for that from the beginning. Plus, platform as a service providers make it so easy to try an experiment with different technology stacks, there’s really no reason not to start with this approach.
• Keeping up with the craft.
  I need to keep up with the state of the art, so that I can remain vibrant, creative, and competitive in the industry.

So I shared with the group a few tools that have helped me to continue to grow in these areas:

Super Awesome Code Completion

• http://emmet.io

Project Scaffolding

• http://yeoman.io
• http://brunch.io
• http://getbootstrap.com
• http://foundation.zurb.com

Platform as a Service

• http://dotcloud.com

Browser-based online IDE

• http://c9.io

And you can see the slides here:

http://www.haikudeck.com/p/IfEWc0USxR/disrupting-your-web-dev-workflow

Webdev in the Cloud: Develop, Version, Deploy in the Browser

Stay with me, old girl!

I have a 6 year old laptop. If I were more cynical, I’d say companies use planned obsolescence to make me buy a new one. With cloud web development, it can still be a useful development machine.

Old Bessy is my 6 year old Macbook Pro. I’ve formatted and reformatted, added memory, and replaced batteries. Even still, I’m having a hard time using her for modern web design and development. She’s stuck on Mac OSX 10.6 Snow Leopard, since Apple won’t let me put their latest operating systems on this hardware. Apple also doesn’t make the latest versions of XCode or their command line dev tools available on this machine. Adobe won’t let me put CS6 on her. Can’t use front end dev tools like yeoman.io. While those new Macbook Pros are skinny and sexy, I’d rather not spend cash on a new laptop.

But it’s almost 2013…everything’s in the cloud these days, right. How can I do my web development work in a browser, using cloud tools?

Web Development in the Cloud: Requirements

In my day job and side-consulting jobs, I need to be able to quickly throw up HTML design prototypes. In order to make a cloud-based web development workflow work, I need to be as productive as I am working on a local dev machine:

Must Haves

• A modern text-editor/IDE (code highlighting, suggestions and auto-complete: I currently use Sublime Text 2 or Textmate)
• Git version control
• Development server, either for quick static/HTML only demos, and more complex client-server-database sites (django, rails, I’m started to play with node a bit).
• Automated deployment to production level servers, via SSH, FTP, git, or whatever means.

Nice to haves

• Watch and auto compile SCSS and coffeescript
• Live reloading after HTML/CSS changes
• Persistance layer (database, nosql, filesystem, etc. Most of the time, I’m doing front-end/interaction design type prototypes, so I don’t need this every project)
• Free

The secret sauce that makes everything go is the Cloud9 IDE. I’ve been watching them on and off for a while, checking it out, playing with it here and there. The collaboration/sharing always seemed neat. But at the end of the day, it didn’t support the tools I use or the way I work. But then I saw that Cloud9 has embedded a fully functional terminal/command prompt inside their IDE:

That is a full-blooded terminal inside Cloud9…Below the surface the terminal is connected directly to the underlying infrastructure.

…the terminal is nearly indistinguishable from a regular terminal, with one massive difference: it’s running on the web. You can access it from anywhere, without any duplicate configurations, and even share the workspace with a friend so they can connect to it.

As far as I can tell, you can’t sudo, or open arbitrary ports. But it appears you can do just about anything else that you would expect to be able to do with user-level permissions. Python and ruby are available, you can run easy_install and install gems. Heck, you can download, install, and run a database! Of course you can ls and look around…even edit files in vi if that’s what you like.

Opening up the terminal in a full unix session inside the browser is a game changer for me. I can take my existing tools and workflow and make them work within a browser! I can work on my computer at home, my parents computer, the netbook that’s been gathering dust since the iPad came out, and have the same web development environment everywhere.

Cloud Development Workflow

Set up Github Repository

• Create a new empty repo in github. Cloud9 also plays nicely with bitbucket, and can clone from any git URL.

Start Your Project in Cloud9 IDE

• Clone this new repo into Cloud9, and start editing. Cloud9 can connect to you github or bitbucket account, and will automatically show you any repos you have.
• Make some code. You can, of course, use the functionality in the Cloud9 IDE to add files and edit them, but I don’t want to start from scratch. I’m gonna just pull in Twitter Bootstrapand their fancy marketing narrow example. From inside the Cloud9 editor I press Alt-T to bring up a terminal window. I can run pretty much whatever unix commands here, including git push back to github, or wget to pull the Bootstrap code I want:

  wget http://twitter.github.com/bootstrap/assets/bootstrap.zip
   unzip bootstrap.zip
   wget http://twitter.github.com/bootstrap/examples/marketing-narrow.html  //Here I had to update the HTML so that the bootstrap css/js files point to the right location
  
  

• Preview your new site. With Cloud9, you can run a server-based node, python, ruby, or php app with their Run and Debug settings. But since this is just static, the simple Preview button works fine.

Deploy to Infrastructure-as-a-service provider

Cloud9 comes with close integrated with Heroku and Microsoft Azure. I happen to like dotcloud. With dotcloud, I can easily install the dotcloud command line interface right into my Cloud9 infrastructure, and use dotcloud to deploy the site. Per the dotcloud instructions, install the command line client, create a instance and dotcloud.yml file to create a static www server, and push your project up to the new servers!

easy_install pip && pip install dotcloud
vi dotcloud.yml //or you can do it from the C9 IDE
dotcloud create c9dotcloudgithub
dotcloud push

Mine ended up at here: http://c9dotcloudgithub-fitzgeraldsteele.dotcloud.com/marketing-narrow.html

Version Control and Push to Github

Finally, you’ll want to version that code, and push it back up to the origin at github.

• Create a .gitignore file: I ignored the .dotcloud directory, and the .c9revisions files.
• Stage your code: git add .
• Commit to your local repo (this one is stored on cloud9) git commit -m “Initial commit from Cloud9″ (use the command line, or the pulldown menu
• Push back to github: git push origin master

Conclusion

Like the Cloud9 blog post said, this is all pretty straightforward with one major exception: I did this all inside a browser window! I still need to explore what all can and can’t be done inside the c9 terminal, but I don’t see why I couldn’t install the scss/coffeescript watchers to get some of those nice to haves. I’m really excited to see how much of my web development needs can be handled with cloud systems through the browser. I’m also interested in learning how much can be free, and where to get these best bang for the buck in paid services. Looks like Old Bessy may still has a few good years in her yet.

What would your ideal cloud web development stack allow?

Bootstrap Icons in Sitefinity Hack

The Bootstrap framework includes a bunch of awesome icons, which you include in your markup using a custom <i> tag. But some tools (ahem, Sitefinity CMS) like to autocorrect your HTML, so it doesn’t play nicely with the <i> tag. But you can use a DIV instead.

So instead of:

<i class="icon-remove" />

use:

<div class="icon-remove" />

Bash Shell One Liner: Find and compress files

Mostly wanted to write this down so I can find it later…

This bash shell snippet will search a directory tree for files matching a number of regular expression criteria, and then add them all to tar/gzipped file.

find -X . -name "*201009*" -o -name "*201010*" -o -name "*201011*" | xargs tar czvf ~/Desktop/corplogs.tgz

I was using the Mac OS X terminal…this took me a long time to figure out because all the find tutorials on the web have the find criteria inside parentheses.  Apparently the parentheses aren’t necessary in the Mac terminal.

In this case, I was looking for log files between September 2010 and November 2010.  The “-o” argument is a logical OR.  The find command spits out a list of file names, and xargs bundles them up and passes them to the tar command.

Is Mobile Design Really That Different?

I’ll be honest.  I’ve only dabbled in the mobile app design and development space: one app for fun, one app for work (hopefully to be released in the next couple months).  At today’s iPhone Design Conference, Brian Fling argued that mobile design is totally different that web.  But I still don’t see how mobile app design and development is that different from traditional software or web development.  Mobile devices offer new capabilities and require learning new tools, but the fundamental design and development tasks remain the same.

Mobile design reminds me of designing desktop apps in the late 90s.  Multiple platforms, small screen real estate, limited computing resources (although an iPhone would probably

Back in the day, VisualAge for Java provided a way for designers and developers to jointly build "cross-platform apps." It used a drag/drop GUI editor to generate java code. In other news, I'm old.

run circles around my 486).  Each application was an island, with little or no way to share information or task flows between them. Users probably didn’t have that much experience with computers.  Your job as a designer was to understand the users key tasks and success criteria, and  iteratively perform design and development to reduce time on task or errors.  You differentiated your product by closely aligning the user interface metaphor with the users’ mental model of the task or process.  Back in the day, we called this User Centered Design, and later Usability Engineering.  Over the next decade, hard drives got bigger, screens got bigger, processors got faster, and networks and application mashups were everywhere.  Users learned what to expect on websites.  We designers stopped talking about usability — how well do people get through the task flows we have created — and started talking more about a more holistic User Experience.

Mobile application design exploded with the iPhone.  Again, we find ourselves designing around constraints of small screens, multiple platforms, and limited computing resources.  This time around, however, we’ve got some additional capabilities.  Geolocation, gesture and multitouch interfaces, photo and video streams, anytime/anywhere network availability.  We have cloud processing and data storage that we can use to offset device limitations.  Even better, we have a generation of millions of users that are eager to embrace new technologies, pretty much willing to pay for and try out whatever we can think up.

But some things haven’t changed.

The basic cognitive and physiological capabilities of people haven’t changed.  We’re still resource constrained people, who can only focus on one thing at a time, have relatively shoddy memories.  We can only get our fingers to click on something so fast.

We all have the same basic needs.

Because of these basic human traits, designers still have to take care of the same basic interaction design requirements:

• Visibility (also called perceived affordances or signifiers)
• Feedback
• Consistency (also known as standards)
• Non-destructive operations (hence the importance of undo)
• Discoverability: All operations can be discovered by systematic exploration of menus.
• Scalability: The operation should work on all screen sizes, small and large.
• Reliability: Operations should work. Period. And events should not happen randomly.

As Don Norman recently pointed out, we’re not doing a great job with this on gesture interface devices

When we build these interactions, we’re still not doing it by ourselves.  We want to continually align our designs with users expectations and developer feedback.

We still need to understand users’ mental model of the task domain first and foremost.

Mobile gives us some new tools in our design toolbox, and we lose the assumption that the user is sitting at a desk, working on a single task by themselves.  New device capabilities…natural voice control, natural human gestures, thought controlled interfaces, semantic or linked data…are in active research and will make even more things possible.  But the basic job of the UX designer is still the same…to use the resources available to make our users more efficient, effective, safe, and if we’re lucky happier.  We still need to work iteratively with developers, business stakeholders to make that happen.

Am I missing something?  Am I thinking about it at the wrong level of abstraction?

On a side note, I’ve previously discussed that UX Designer/Developers should have a strong foundation in human factors, psychology, and computer science.  I think that (and experience) gives you the background to see beyond the new shiny toys and identify the real trends and innovations.  Jared Spool seems to agree.

jQuery Quickie: User Feedback with Fade Out/In

Here’s a little jQuery idiom I’ve come to use on a few web design projects that I thought might be nice to share.  Let’s say you want to update a region of the page or widget based on some user action.  For example, you might be building a screen with a list of orders on one side, and an details panel on another.  Clicking on one of the orders replaces the data that shows up in the details panel.

I use this snippet when I want to visually reinforce an on-screen change that happens when the user takes some action.

$('#link').click(function(
  $('#content_container').fadeOut("fast",function() {
     updateContainer();
     //other code here
   }).fadeIn();
);

(view as Gist)

Pretty simple jQuery, really.  When the user clicks on the link, we want to swap out the information in the content_container with the new data.  This simply chains together a nice set of animations to:

1. Quickly fade out the #content_container,
2. Do something to update the #content_container.  Or whatever you want really.
3. Fade in the #content_container after all the updates are complete

I personally like the fast fade out, normal speed fade in.  I feel like it gives the user a nice visual indication that something in this area changed, without drawing out the animation or drawing attention to the fading effect itself.

On a side note, this builds on some things I learned from Bill Scott at this year’s Web App Master’s Tour.  He presented a nice framework for thinking about all the small ways designers can provide useful user feedback without drawing attention to the animation or UI itself.

Why use NoSQL instead of mySQL?

I’ve been watching/reading all the hub-bub about NoSQL databases.  This is the part of the blog post where I briefly recap the NoSQL movement: schema-less, key/value stores, document stores, yadda yadda yadda. But you have Google too.  (Although this one is my current favorite).

I’ve got a couple applications brewing, both for work and personally.  So how do I evaluate NoSQL vs MySQL?  When should I use NoSQL instead of MySQL?  When should I use NoSQL instead of any RDBMS, for that matter?

After reading about NoSQL, downloading a couple, trying a few tutorial, this is what I’ve come away with:

• It seems to me the primary advantages of NoSQL over MySQL or another RDBMS are speed and scalability.  From everything I’ve read, NoSQLs tend to be hella-fast for a variety of reasons.  Depending on the particular system, it is fast because: the entire DB is stored in RAM, or you do fewer JOINS due to a document store, or an extremely efficient B-tree data structure, or Map/Reduce, or others.
• The big bonus for MySQL is, of course, ACID compliance.  The database helps ensure that you save the only data you wanted, when you wanted to save, and that it’ll be in a good state when you need it.  If you have something like a bank, you want that kind of data integrity.  If you’re serving millions of status messages, you may not care as much that everything is exactly right, or that everything is consistent at every instant across your data cluster.
• I think an equally important (though I haven’t read about it very much) is that NoSQLs may be a simpler, more natural way to conceptually model the data in your application.  In document stores like CouchDB or MongoDB, I just add new fields to a document.  Just like I was writing extra information on a piece of paper — I don’t have to update every other piece of paper in my filing cabinet.   It may make sense to think of you data as a document, rather than scattered across various relational tables.

As I’ve said a couple times in this blog, it’s all about picking the right tool for the job.  When I am designing a web site for a client, I have a number of tools I can pick for wireframing and prototyping.  When I’m coding a site, I have a number of web frameworks, programming languages, and coding guidelines I can choose from.  In the same way, NoSQL gives people another choice for persisting data — one that is 1) easier to get your head around than relational databases, 2) addresses some scaling and speed issues that rear themselves at high volumes, and 3) is relatively cheap or free to use.

If I’ve missed something major about the relative merits, I’d love to know about it.

I’m choosing to use MongoDB in some of my personal projects because I want to add a new technology tool to my toolset.  But for work, given our current usage and application needs, I can’t imagine seriously trying to roll NoSQL into a production system in the near future.  I’m not saying our IT Ops would laugh at us, but there’d be a fairly high burden of proof.  In terms of modelling data in our applications, I can’t think of something that in NoSQL that I couldn’t do in an RDBMS.  Again, I’d love to know where I’m wrong in this. One day, our loads or speed requirements may force me to revisit this assumption.

URI Routing in Expression Engine, CodeIgniter, Django, and Rails

One of the reasons I think I’m having trouble grokking Expression Engine (EE) is because it has a slightly different take on the MVC paradigm than I’m used to from its cousin CodeIgniter, or other web frameworks like Rails or Django. ExpressionEngine seems to focus on the View (or template in EE-speak), where those other frameworks have you spend more time on the Controller or Model.

Let’s look at URL routing…how does the URL map to the code that gets executed and rendered in the browser? Let’s make it a simple example where we’re implementing a site with a structure like this – A Home/Overview page with a few sections, and each section has a couple pages:

Home
|-Section1
|
|-DetailPage1
|
|-Section2
|
|-DetailPage1
.
.
.

I want to have URLs like this:

/home/

“Home page” of the site, with it’s own glossy template with prominent links to each section:

/home/section1
/home/section2

Section home pages. These should have the same look and feel, although populated with different data. (And I don’t want to hear from you REST people saying it should be /home/section/1 — this is just a generic example)

/home/section1/detailpage1
/home/section2/detailpage1

Details pages for those that really want to dig into the subject. These should have the same look and feel even though their in different sections.

Got it? Great…let’s compare how to do that in various frameworks:

Expression Engine (v1.6.8 EE Core, although v2.0 is in beta)

Routing Method: Template Based

EE maps urls to template groups and templates in this format: /template_group/template/parameter. I can get the Home Page URL I want by setting Home as the name of my template_group, and define a default template named index.

I haven’t found a good way to get the section page URLs I want.  The few ways I tried all seemed suboptimal:

• I could create a new template for each Section, but that seems like overkill — may as well write plain HTML for each page.
• I could overload the the Home/index template to show something different based on the second segment of the url (if segment_2 =! ” do something.  Now I’ve complicated my template.
• I could make categories for each of the sections, and create a single entry for each category to show the details.  But using the category tag enforces that you have a category delimiter in your URL, so now my url path will be something like /Home/category/section1/list

The solution I’m driving toward is changing my around my URL structure so its:

/home/list/section1

/home/list/section2

I added a new segment to my URL structure. I have a template named list, which then uses the section name as a parameter to pull the correct weblog entry.  I can do /home/detailspage1/section1 in a similar manner.

What if I want to add more levels to my hierarchy, like /home/section/detail/moredetail/errata/? I don’t see how to do that in EE Core. I need the Pages Module, which comes with the paid version, which allows you to explicitly set the page URI and template.  But my budget doesn’t allow me to sink cash into this for an experiment.  I could also try out the Structure 3rd party Add-On.

CodeIgniter

Routing Method: Filesystem Based

CodeIgniter maps URLs to controller classes and methods.  So given the url /home/section1/detail, it’s going to find the controller class named ‘home’, and execute the ‘section1′ method with the ‘detail’ passed as a parameter.  In the section1 you can return arbitrary HTML, or render a view — normally an HTML file with variable placeholders.  You can make a deeper hierarchy by 1) placing controllers in a nested directory tree, or 2) customizing the URI Routing rules, similar to how its done in Django and Rails.

Django and Rails (and CodeIgniter advanced)

Routing Method: Explicit URI Routing Rules

In this paradigm, the developer must open a URI routing file and write code that tells the framework to run a particular controller method when a URI is requested.  Very often you use regular expressions to make routing less verbose/more generic.  Let’s say we were doing this example with Django – I’d write a couple lines in urls.py like:

(r’^home/?P<sectionname>(\w)+’, project.app.controllername.function)

Which would tell Django to run the app.section.controller.function, passing in sectionname as an argument (yes, I know in Django they call them views instead of controllers).  Inside the controller is the code to pull the appropriate data from the database.  Rails is similar, although with Scaffolding it makes a lot more assumptions about how you structure your pages and controllers, and do some of this routing for you.

With this style, the extra complexity buys you more flexibility.  You can define any URL or URL structure of arbitrary hierarchy.  Here, your coding efforts are in the controller rather than the view/template — the view just renders the data it is given.  One benefit of this is that your template developer doesn’t have to know as much about the data structure, and can work more independently of the coding/data.

Conclusion

Once again, pick the right tool for the job…

I guess EE’s focus on templates speaks to its target audience. It started life as a simple blogging system, and grew/morphed into a more general CMS. So it has a relatively simple data model and controller, and instead makes you spend more time on templates, where the target audience is probably most comfortable. CodeIgniter, Rails, and Django on the other hand are targeted to a more technical audience…people that built web applications by hand but now want tools to make that job easier. So in those frameworks you spend most of your time customizing the data model, and specifying the controller behavior. The templates are relatively dumb in comparison.

Also, I’m guessing EE is or was targeted to single or small teams of developers/designers building a site either for themselves or a client. The result is that there is a lot of interplay between the data and the templates, and teammates have to be in pretty close contact to make sure everything works. Contrast this with Django which grew up in a newspaper environment with lots of contributors. They needed a system where designers, developers, and content writers could work relatively independently in order to meet a short deadline. So I feel like that framework better separates the concerns.

It would probably be a more fair to compare ExpressionEngine to something like WordPress or MovableType — other blog engines that have blossomed into content management systems.  Wordpress even won 2009 Open Source CMS of the year, so that really is something to investigate.

This whole diatribe is predicated on the assumption that the URL structure is important to anyone. Maybe I’m trying to uphold some strange kind of RESTful ideal that isn’t practical. Certainly the client for this project doesn’t care. I only care so far as the framework acknowledges that my information architecture is going to change and grow over time — categories will come and go, new subsections will be added.  I see the RESTful pattern as a way to organize the information structure in a scalable way.  Frameworks that facilitate the RESTful style, and follow a more traditional MVC build approach,  more cleanly separate the various parts of the system, and make it easier to change and grow the IA over time.

Learning Web Frameworks: Expression Engine, Acquia Drupal, Ruby on Rails

I work for a corporate website team.  When our internal ‘clients’ want a new web project — new page, contact or registration form, major page redesign, etc — they download, print, fill out, and mail us a paper form.  We recognized the waste involved with this paper form, and the irony that the website team does not have a web enabled project request form.  We do most of our work in base PHP, but we’re also evaluating various web toolsets/frameworks/CMSs to adopt for more of our projects going forward.  So we used this small form as a little case study.  Let’s implement this form in a number of different tools.  That way we get practical experience in these different technologies, and we can see first hand what attributes we’re looking for in a web framework.

Project Requirements

We met for a half-hour just to make our project requirements explicit.  We documented the requirements in a story map, and made a quick wireframe:

• Client enters their contact details (name, department, phone, email)
  • Optional: Pull the contact details from the enterprise LDAP server
• Client enters project details (name, description, budget code, deadline date, and whether the project has VP approval)
• On submission, show confirmation page and email confirmation to client.  Also send email notification to our project managers that a new request has been made
• Members of our team may view the list of projects (especially budget codes, which we need for our time sheets), and see project details
• Project managers can add an estimate (number of hours we think the project will take), and estimate description
• When the estimate is created, automatically email an estimate to the client

Now, to build it…

Expression Engine

I got the sense that Expression Engine started its life as a blogging only platform, and someone said, “hey…we could probably use this as a general purpose CMS too!”  I felt that if I wanted a blog or multi-blog site, EE would be great, but we clearly did not understand the “EE Way.”  EE does not come with a form builder out of the box, but we found the FreeForm module which got us on our way.  There’s no GUI form builder or admin panel; it requires a developer to build the form, which was a major downside for our team.  At the end of a 3 hour sprint, we had an expression engine form, styled how we wanted, submitting project requests and sending the project request emails to our managers, but not a confirmation to the client.  We didn’t get to any edit estimate functionality, and certainly didn’t have a way to email the client when the estimate was made.

We never really felt like we ‘got’ ExpressionEngine. It would definitely take a bit more time to figure out if this is the right tool for our CMS needs. The developers on our team felt like it would’ve been much simpler to just write the thing in plain-old PHP.

Verdict: With 4 people working for 3 hours, we got some minimal functionality, but we must be missing something.

Acquia Drupal

Ahh, Drupal.  Apparantly THE open source CMS.  Yet, to paraphrase Peter Parker’s uncle, with great power comes great complexity — and a steep learning curve.  Acquia is a batteries-included Drupal distribution, with optional paid technical support, which is attractive to our company.  Acquia includes the Webform module, which is a GUI, drag/drop form builder from inside the Drupal admin interface.  While the team was at lunch, I built the form by myself.  Furthermore, the Webform module provides a nice admin interface that allows for viewing all the results, updating entries, even downloading the submissions into a CSV file. One thing I really liked about the Webform module was that it comes with an area where you can post your own custom PHP code to be run after a submission…very cool.  Another nice feature was the conditional emails:  if the submission selects A, email to person A; selectB, email person B etc.

I had it in the default Acquia Marina template.  I don’t think we really get how to use Drupal’s templating system yet, so I’m not sure how we would apply our own custom styles/templates.  But I’m confident that we’ll be able to understand Druapl templating before Expression Engine internals (which is based on CodeIgniter — which by the way I really like as a web framework).

Verdict: The webform module is the bomb: 1 person, 15 minutes, done.  Not sure how to bend Drupal templates to make it look how we want, though.

Ruby on Rails

I’ve been looking for an opportunity to try a non-blog/wiki type rails app.  I checked out the Heads First Rails book from the local library, which taught me a lot.

It turns out Rails is tailor made for this type of job.  Rails scaffolding gives you an Apple-esque out of the box experience.  One command line basically got the full app functionality.  Given the name of the database model, and a list of field names and types, rails generates a database model, and the controller and view code for basic CRUD functionality:

ruby script/generate scaffold project first_name:string last_name:string email:string phone:string project_name:string project_description:text date_needed:date budget_code:integer vp_approval:boolean

Rails just really gives lots of tools to do the things you probably want to do on a web app. Need to add/change the database schema after the initial generate?  Migrations are your friend.  Send emails that get triggered on code events?  Use Active Mailer (ruby script/generate mailer) and you’re mostly done.  The views/templating/partials makes sense.  Scaffolding also gives you infrastructure for unit tests and acceptance tests (via the Cucumber behavior driven development framework).

So I was super excited about how quickly I could get something up and running.  I call over one of our graphic artists and one of our project managers to give them a demo of how to create, scaffold, migrate, and configure a rails app.  And I got mixed reactions.  Yes, scaffolding is impressive,  but you still have to be a bit of at techie/programmer to understand how to do it.  I think they were a bit intimidated by the command line knowledge required, as well as the need to learn a new programming language.  As I created a number of apps to show different parts of the generate/scaffolding script, the PM noted, “well, it looks like sometimes it’s easier just to build a whole new application rather than fix one.”  I thought that was insightful…she recognized that the auto-generated code makes it really ‘cheap’ to build a new application.

Verdict: Convention over configuration is great, as long as you can learn the conventions.  Once I started to learn the conventions, I could do a lot in a very little time.

Conclusion

At the risk of sounding cliché, you have to pick the right tool for the job, for your team.  For this single, stand-alone project, we’ll probably roll with the Rails app.  We can get that up and running super quickly.  I don’t know that we would ‘bet the farm’ for our entire site on Rails just yet, though.  Big learning curve for our department.  We’re really looking for a content management system.  We’ve got several instances of WordPress we use, so we’re used to that.  Personally, I’m leaning toward Drupal.  Yes, high learning curve, but it has a really flexible content model, lots of modules, an active developer community, support for workflow and fine-grained authentication/authorization.  And, with Acquia you have commercial support.

But of course the door is still open, and we’re looking at other toys to play with.  I’m going to try doing this form in Pylons, which looks heavily influenced by Ruby on Rails, with a couple advantages 1) written in python which I already know, 2) less opinionated about which tools you use at various points in the web stack.  It scaffolds a rest style controller, but not the views, models, or tests.

Agile2009 Recap

I had planned liveblog the Agile2009 sessions I attended, but ran into a couple roadblocks*.  You can see the Agile2009 sessions I DID blog.  Also, Jackson Fox went ahead and wrote a great recap from a UX perspective.  It might be more interesting for me to talk about how well I accomplished my goals for attending.

I had three goals for attending Agile2009:

1. Learn methods, tools, and best practices for improving my user experience (UX) research and design,
2. Help my department to adopt Agile practices in order to respond to increasingly demanding projects and shorter deadlines, and
3. Learn ways to more effectively team with colleagues in other parts of our organization to develop and deliver outstanding UX on our enterprise tools.

I was a blend of several of the conference personas: obviously Deanna the UI Designer, but I also felt some affinity for Carlos the Internal Coach, Peter the Programmer, Alex the Architect and David the Developer, even Tara the Tester.

Agile UX Research and Design

I’ve already blogged about some of the UX sessions I attended.  I would say that there were two broad categories of UX sessions (at least, that I attended): Agile UX methods and processes (guerilla user research, persona development, task analysis grids or storyboards) and experience reports (how do we do UX on an agile time schedule, with an agile development team).  The method and process talks were very high level — almost introductory, and I felt didn’t really have enough time to get into any kind of real discussion on how to really use these UX methods in real life, anymore than reading about the techniques on the web .  I did appreciate the 3 hr tutorials from Jeff Patton on Personas and Mike Cohn on User Stories.  Coming out of those, I felt like I got a bit of ‘meat,’ which I could chew on — they gave a good framework for how to think about using these tools, instead of just a technique.

From the experience reports, the main message I got was, “here’s what sort of worked for us…we had to be agile and learn, and this is what happened in our shop…good luck with yours.”  I had a hard time seeing how some of these were generalizable, or how I might use some of the lessons learned.  Clearly, everyone is feeling the time pressure for faster deliverables within Scrum sprits.  This means that UX practicioners have to be UX generalists: skilled in visual design, info architecture, interaction design, even development.  I think the best takeaway was just networking with the people giving and attending the sessions, and finding a community of people I could talk to about approaches I’m thinking about taking.

I was a bit saddened and disillusioned at the perceptible distance between the UX and Agile Development community.  The developers are still saying, “I’ve gotta get this code feature out the door, I’ll let you know when I need to talk to a designer), and the UX people are still asking, “how do I get the working respect and integration with the development team.”  One concrete example of this: Todd Warfel and others did a set of three sessions on the whole ‘Agile UX process: Performing User Research, Distilling and Communicating Research Results (mainly via personas, and finally developing wireframes.  I noted that the user research sesssion was sparsely attended and almost solely by UX people, the session on personas had a few more, and the session on wireframing was jam-packed.  I think this is another example of developers trying to see how to get straight to the design, even though designers know there’s a process involved in getting to the design.  Not sure how this dichotomy will play out.  I don’t think anyone does yet.

Overall, definitely a positive experience, though.  I was really impressed with the LiveAid stage…several UX designers did some agileux methods (guerilla user research, personas, wireframes), then teamed with several agile developers at the conference to create an iPhone app for a non-profit: http://www.manoamano.org.  In addition to raising nearly $5000 for the charity at the closing banquet, the exercise of doing UX research and design, development and shipping a live app in 3 days was inspiring.

Agile in our Department

At my company the webteam is undergoing a bit of an evolution, where are roles are changing from simply maintaining the public static websites to designing and developing some mission-critical web applications.  Our internal clients are asking our team to provide new (to our company) types of online interactivity and functionality, and the demand for us to be a mini-IT department are increasing.  What agile tools/options should we look at in order to keep with the demand and still deliver outstanding webapps?

One way I think we can improve is to better integrate unit testing, acceptance testing and continuous integration into our team workflow.  I went to a couple talks on CI – I think mostly by CI software vendors.

I went to a couple agile coaching sessions to get a sense for how to ramp up teams, and get people started doing things an ‘agile way.’  I was impressed by some of the coaching start up team strategies shared Lyssa Adkins. The session on user stories from Mike Cohn was again a great example of how to collect/gather/uncover requirements.  In the OpenJam, I poked my head in on some people review Kanban project management.

One takeaway here is that ‘agile software development’ is more of a mindset change.  It’s a set of principles, from which several methods, tools, and best practices have been developed.  But as warned on numerous occasions, just adopting some or all of the methods without understanding the principles often leads to poor results.  I think the key here is to focus on the core principles, and adopt the set of practices that make sense for your team wherever they’re at.  I like the idea of the Scrum style — setting a sprint timebox for a delivery of something of business value, and then meeting afterwards for a retrospecting and planning of the next sprint.  I’m planning on experimenting with a WIP board for a short sprint on a project this week.

Another takeaway is that, at the end of the day, all these agile documentation and project management methods and tools (user stories, personas, work in progress boards, pair programming, Scrum, Kanban, Blitz Planning) aren’t really rocket science.  They all center around creating externalized, shared visualizations of the problem and solution spaces.  The goal, it seems, is to extract the implicit knowledged wrapped up in each team members’ head as simply as possible, put them in a shared accessible place as simply as possible.  This allows the whole team to see the whole picture, and allows communication and ideas to flow as quickly as possible.  That’s why agile emphasizes small, co-located teams over large distributed teams — fewer barriers to communication.  That’s why agile emphasizes user stories on index cards, simple personas, and face to face communication over documentation — its easier to exchange ideas and information, to re-arrange and update the knowledge-base.  Agile emphasizes working code as documentation because the working code is a clear concrete thing that the entire team can gather around and say, “yes, this is right” or “no, it should be some other way.”

Agile in our Enterprise

I’m going to hold this for a future blog post…this one is long enough as it is.

Other Conference Observations

• I thought I’d be hearing lots of people at this conference saying, “do it in Rails” or “Django” or <name your new-fangled web framework>; I was surprised at all the java and .NET technical talks.
• I loved the Musick Masti sessions over lunches and at night.  I got to go down a jam on a sax they had there, as well as play various percussion and other instruments.  That was a lot of fun.  That seemed to be a theme the conference organizers were going for…things should be fun!  The Monday night social/networking event was a good example — various wiis and other games were strewn about the vendor hall providing opportunities to interact with other people through games.
• SO…MUCH…SWAG.  Wow…I brought home almost a whole suitcase full of free books, balls, silly putty, race cars, planning poker cards, t-shirts.

* 1) dodgy conference wi-fi access.  You’d think ubiquitous wi-fi access would be a given at a techy-geek conference like this.  It was great in the Open Jam area where people could congregate and talk about whatever, but it wasn’t as good elsewhere, 2) my Airport wireless card has been giving out for the last few weeks, and finally died at the conference.  Luckily, the Chicago Apple Store is not far from the conference venue — they sent it in and fixed it for free, even though my AppleCare expired in April (I love Apple’s customer service, and the fact they know that I’m pro