Fitzgerald Steele

Wired says that blogs are dead, and that Flickr, Facebook, Twitter, and YouTube like sites are the future.  They argue that the ‘blogosphere’ has been overrun by commercial sites, paid authors, and underground marketing, and that brevity and/or multimedia nature of these new tools further evens the playing field.

Is this up for discussion?

In my opinion, this article ignores the ‘long tail’ phenomenon of weblogs/social media (a phrase that was coined by Wired).  In short, while there are only a few mega-popular sites, there are so many people online with so many varied interests that even micro-niche sites can be successful.  No matter how narrow your focus, there are likely to be thousands of people out there with the same interests.

Flickr, twitter, Facebook, and similar tools are good for capturing moments, and answering questions like “what are you doing now?”  They’re a great way for me to share with friends, family, and colleagues things that are going on right now.  Blogs, however, are probably better at transferring knowledge and insight, or answering questions like “how do I configure PHP to make my website work?”

I don’t even think video-blogging will make a dent in text-blogging.  First video search is really hard.  Google is starting to address this with Election speeches, IBM is working on it too.  But there’s way more to be done.  Yes, I’d like to search things people say in video, but what about searching by location (I want videos from Paris; I want videos inside a garage — a home garage, not a repair garage) or by events (I want videos of the Iowa Floods of 2008).  Second, text is better at allowing people to navigate, jump around hyperlinks, and find the information they want.

I guess its a matter of picking the right tool for the right job.

- J

As I mentioned last week, I’m using Pinax to test a new website for my research lab.  The site is now in private alpha, which means I’m getting some internal users to log in, test it out, and give me feedback, and I don’t think it will fall over.  I’m writing up my experience to 1) help others get started quickly, and 2) start talking about how the pinax community can get people ramped up faster.

My background:

• Journeyman Python Programmer. Can independently write code, diagnose most problems.
• Journeyman HTML/CSS/Javascript. Can independently write code, diagnose most problems.
• Some experience doing apache configuration, though not recently. No experience with mod_python or mod_wsgi. I largely rely on documentation and examples found on the interwebs.
• No major prior experience with django, and none deploying it via Apache/mod_{python,wsgi}. I almost exclusively rely on documentation and examples found on the web (although my python experience helps)

The nice thing about pinax is that it has an active community; in particular an active IRC channel (#pinax on freenode). The pinax maintainers have been there, patiently answered my newbie questions, and got me going.

Step 1 – Get the base pinax software running.

Download and install django and pinax.   I first did this on a WinXP desktop. Crap. The templates aren’t rendering properly. I try commenting out the offending lines in the templates, but problem after problem comes up. Jump on #pinax.  Did you do seed the database with manage.py syncdb?   Uhh, no.  I do that, but still having problems.  Back to #pinax.  Are you running WinXP?  Why yes!  Oh, pinax on Windows has a known bug (which really is caused by one of the external apps they rely on).  Copy some files to a new location, or install on an OS which supports soft links.  I choose door 2, recheckout on my Ubuntu machine, sync the database, run the django dev server ( manage.py runserver) and we’re good to go.

Step 2 – Make sure everything in the base site works as expected.

The pinax project comes with a complete working example under the directory projects/complete_projects.  I copy this to a new directory so that I can refer back to the complete_project in case I screw something up.  This means you have to change the ROOT_URLCONF in the settings.py

Added some users via the admin interface…looks great.  Added an account via the Sign-Up page.  Accounts are created (with or without OpenID), but no confirmation emails are being sent.  Hmm  Check out the included django-mailer app, which uses the same configuration as the standard django.core.mailer.  We need to add some settings to settings.py: EMAIL_HOST, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD.  I set these to use my gmail account to do email.  But really, it’d be better to have the emails coming from the local machine, and I really don’t want to hardcode my gmail password into the config file.  I need sendmail on this machine (sudo apt-get install sendmail).  Now that the local machine has its own SMTP server, I can remove the EMAIL_* settings from settings.py.

Hmm…emails still not going out.  Let’s look at the django-mailer docs.  Oh, I see…email messages aren’t actually sent until manage.py send_mail is run from the command line.  The recommended solution is to add a couple lines to the system crontab so that they are run regularly (this is now much clearer in the pinax deployment docs).  Now we’re sending emails!

Step 3 – Configure templates, images, and site text for our lab.

Ok…first thing is that the default site says ‘Pinax’ everywhere.  I need to change that to the name of our lab, GROK Lab.  There’s an outstanding ticket to use a SITE_NAME variable in settings.py which would be displayed throughout the site.  Until that gets resolved, we just have to find all the hardcoded [Pp]inax strings are replace them with the SITE_NAME variable.  I just used grep to find them all, and then I replaced the ones I needed to replace (I left things like Built with Pinax, About Pinax, James Tauber is the awesomest creater of Pinax ever, etc).  Pinax has several translations available, which I think means that I should have been making most of my changes to externalized text strings in locale/en/LC_MESSAGES.  But I didn’t, and just changed the template files.  I’m not sure what will happen when another language is selected.  Should learn more about django internationalization.

Update 11/14: Fernando Correia did some more digging on how to properly externalize strings in django.

One particular place this got me into trouble was, again, the django-mailer app.  Invitations to join the site are generated via two templates: templates/friends/join_invite_message.txt and templates/friends/join_invite_subject.txt.  I wanted the subject of my email to say “You have been invited to join the new SITE_NAME.”  I tried to use the variable substitution syntax {% site_name %} but got an exception that I couldn’t use that tag inside a trans tag.  Read more django docs to learn about template tags and internationalization.  I also tried changing the join_invite_subject.txt to use {%blocktrans %}, similar to the other template file in that directory.  Oops.  I accidentally added newlines to the subject template, which django-mailer does not like.  I revert to the original join_invite_subject file, and simply hardcode ‘GROK Lab’ into the subject string.  Hmm…still getting the same error messages about newlines in the header, even though I’ve changed the template.  Oh, the old messages with the bad header are still in the email queue…its trying to send those, not render new ones based on this template.  I clear out the emails with the bad header out of the database via the admin interface, and email is working again.  Whew…

The logo image says Pinax.  That’s no good…I want to replace that with our lab logo.  Everything is nicely styled with CSS.  My image is a slightly different shape than the pinax logo, so I need to change the height/width in the base.css #tabhead .logo img selector to match my logo file (I made our logo the same height as the original pinax logo to simplify).

This is supposed to be a serious research site, so we probably don’t need games (although I played some on cloud27 — they’re pretty fun, and might be a nice way to encourage a more active community).  I commented out the arcade and games apps in the settings.py, all the related ARCADE_* variables, and the URLpattern in urls.py.  Oops…many of the templates expect to have the arcade app installed (for example, the navigation tabs are hard coded).  Use grep again to find all mentions of ‘arcade,’ and comment them all out.

Finally, there were some functionality that the default installation hides if the user is not logged in.  I wanted to be able to have some read views of the people, projects, blogs, tweets available to anyone who visited the site, but only allow writing if they were logged in.  This involved again grepping through the templates for the right section of code, and adding {% if user.authenticated %} … {% endif %} tags.

Step 4 – Configure site to run through Apache instead of the dev server.

So I had the site up and running using the django development server on the default port 8000.  But I needed it deployed through apache so that in case of a server restart, I did not have to restart the site by hand.  The most commonly referenced post for deploying pinax is here.  It gives two sample configurations depending on whether you want to use apache modules mod_wsgi or mod_python.  Which one do I want to use?  What’s the difference between the two?  No idea.  Look up django docs on deployment; it seems to recommend mod_python, so I’ll try that. I wrestle with that for a few hours, but little success.  Back to #pinax, where the consensus is mod_wsgi good, ignore mod_python.  Ok, after another few minutes of messing with my apache site config file, and the pinax.wsgi file, we got it up and running.  A few gotchas:

• Added the appropriate WSGIScriptAlias to my apache site config.  I could view the site; however, I got errors that apache didn’t have permissions to write to the db.  Added WSGIDaemonProcess to the site config and that fixed it.
• I could access the admin site, but it did not have the correct styles/media.  Needed to add an Alias and Directory commands to the apache site.
• Changed the name of the pinax.wsgi to match our site name; need to change the DJANGO_SETTINGS_MODULE variable inside this file

So the appropriate section of my apache VirtualHost configuration looks like this:

# attempt to setup pinax
WSGIScriptAlias / /path/to/your/pinax/project/deploy/pinax.wsgi
WSGIProcessGroup name
WSGIDaemonProcess name user=unixusername group=unixgroup threads=25

Alias /media/ "/path/to/django/contrib/admin/media/"
<Directory "/path/to/django/contrib/admin/media/">
Order allow,deny
Options Indexes
Allow from all
IndexOptions FancyIndexing
</Directory>

When debugging this, it was helpful to watch all the appropriate log files to see what error messages were being generated where: tail -f apache.log apacheerror.log projectsend_mail.log project.send_mail_deferred.log.

Conclusions

Clearly one area where we can improve pinax is the installation experience.  Compare it to the wordpress install experience…download into a web accessible directory, open a web page, short configuration, done.

More difficult to deal with is the fact that, in order to use pinax, you need to acquire at least a passing knowledge of django convention and configuration, apache convention and configuration, and all the external apps bundled with pinax.  This can be a tall order.

Still, I got my site up and running, with much more integrated functionality than I would have had with django alone.  I learned alot about pinax, django, and apache, and should have less trouble on my next site.  And I get the desired ‘oohs’ and ‘ahhs’ and ‘damn, how long did it take you to do this?’ from people in the demo.

The next step is a bit more fun.  Now that I’ve got a basic feel for the technology, I can really think about how to design the site and workflows to best serve the users.

I’ve had fun this afternoon playing with Pinax, and new social media framework based on Django.  I got it up and running very quickly, and with very little configuration (changing template files here and there, styles, etc) I’ve got a brand new website for my research lab that features user profiles, project sites complete with wikis and task assignment, social bookmarking, discussion boards, and a host of other features. I showed it to a couple of my labmates.  They were able to log in and get up and running without any prompting for me, so it seems to have a familiar and easy-to-use-and-learn interface.  Those that were running their own projects enjoyed the project interface, and the ability to link and follow activities of different team members.

I think James and the rest of the Pinax team have hit the nail right on the head.  Out of the box I get about 90% of the functionality I was considering building for our lab.  I’d like to create and and in a django-references app, which would store citation information, who’s read what, who’s written what, etc.

I’m looking forward to seeing how much functionality I can add in how much time.  This type of thing could really transform scholarly communication:)

Joe Lamantia has posted some interesting ideas on the future of information architecture and design.  I really wish I could hear this presentation so that I could understand all the nuances.  I believe the key assumption is that as information becomes more modular, consumable, connectable, and mixable, people will start to build their own information experiences from available components.  Therefore information architects and designers should think about designing frameworks and environments that enable this.

The Web is shifting to a DIY [Do It Yourself] model of user experience creation, one where people assemble individual combinations of content gathered form elsewhere for expressive, functional, and (many) other purposes. The rapid growth of widgets, the resurgence of enterprise portals, the spread of identity platforms from social network destinations to blogging services, and the rapid increase in the number of public APIs syndicating functionality and data, are all examples of the DIY shift.

I think this assumption that people will want a DIY web experience can be debated.  Surely, there are some alpha-geeks that are extremely comfortable building and using technology to suit their specific needs.  By virtue of reading this post, you are likely one of these.  I would argue that most people — your grandma, your mailman, your barber — don’t want to spend the time tailoring environments to fit every need, and don’t care enough about information tech to do so.  Most people employ a satisficing strategy, where they go with a solution that’s good enough, rather than going after an optimal design solution. Some examples:

• Take hodrod, customized cars in the 50s/60s.  A few people became expert at building sweet hotrod cars.  They wanted to find the right carborator to fit the engine that they custom built.  And a lot of people envied those souped up cars.  But most people just got in their regular old car and went about their business.
• A few people will build their own computer to get the exact configuration they want to maximize performance.  A far greater number of people will go to their local big box store, or Dell, even Apple, and select one of the preconfigured systems that meets most of their needs.
• In the early to mid 90’s, dial-up internet service providers provided people with internet access (you remember when you finally got to 56kbps, don’t you?).  AOL came along, and sent you a disk with a simple install process.  Millions of people joined AOL, even though you had to use their browser, and could only access services they allowed.
• A few people will host their own blog, photo gallery, etc.  And as Joe suggests, syndication feeds, web services, and widgets are making it easier to mix and mash functionality to make your own site.  But a lot of people are getting a lot of value out of Facebook, MySpace.  Sure, you could build your own site, but Facebook and MySpace hits a lot of the functionality that you want most often.

Satisficing means that people don’t typically search or work exaustively to find the best solution.  Instead they have some criteria for ‘good enough, ‘ and go with the first solution that meets that criteria.  Its why you don’t look through all 1.6M search results Google gives to you; its why you don’t compare results between Google, Ask, Yahoo, Live, and every other search engine out there.

Now, one might argue that Gen Y and neomillenials (people born after 1980, often called digital natives) are more active participants in social media, and are more likely to want to create content.  And a few of those natives will likely create a cool framework or mashup that allows his peers to connect in ways we haven’t thought of yet.  But based on my limited experience working with these digital natives (3 years in grad school, some mentoring, some TAing an intro programming course), most in this age group almost take the presence and abundance of technology tools for granted.  I don’t believe they want to build or tailor an experience; they expect the experience to be there, or will come along soon, and don’t care to expend the time/energy to create it.

Given that, I think the future is bright for excellent designers, user experience researchers, ethnographers to understand the wants, needs, and environments that people consume information products, and design solutions that meet those needs.  Yes, we need good frameworks to enable more powerful, effective, and efficient information products.  But people want, and will continue to want, excellent experiences given to them, rather than taking the time and effort to develop their own.