Drupal Learning Journal 22. Drupalcamp day 1

I am at my first Drupalcamp (a conference where training and discussion on Drupal is happening) ever and loving it. It is at Stanford. This morning, I wanted to check directions and parking instruction on the event’s site, but they changed the design and it was so bad that I couldn’t read anything on it. I should have taken a screenshot of it to show it to you, particular that by now (evening) the design has been restored to its regular and functional version. As a result of my imperfect instructions I parked more than a mile away from the correct location on campus, so I had to rush through campus in the hottest and most humid day of the year. (I didn’t make that up. I am staying with my cousin, who has been a professor here for 6 years, and he said that he never experienced such a day here.)
I signed in 15 minutes before the first session and mentioned that the site was illegible. They reminded me that it was April 1. finally it dawned on me that it was a prank design. And now onto what  learned today on the three sessions I attended.
The first session on “How to Execute an Effective Design Process” was led by Nica Lorber. She works at ChapterThree, a drupal design and training company, that was sponsoring the event.  Her talk was an extended version of her blog entry with a similar title: How To Run A Creative Design Process For A Big Project. A lot of what she shared was not new to me, because of my training in “information science”, having worked for more 15 years with web projects and in general having a mind that is geared towards architectural thinking. Her work, talk and focus was about large projects, with lots of people working on a site both from the developer and from the clients’ end. So far I didn’t find myself in such a scenario, so her tips were not applicable yet, but they all made sense. I won’t repeat everything she wrote on her blog entry that you can read, just sharing some of the highlights of my notes.

• When somebody asks what I like to do I often say that I like to organize large amount of information into accessible ways and chunks. Nica’s personal motto covered a similar idea: “What I am good at: Making sense out of the chaos.”
• Her list of tools was great, despite many of them Mac only. From the non-Mac tools I plan to check out Fireworks and Open Atrium
• Her blog entry includes a downloadable example of all the project deliverables. Very useful considering what they are: project schedule, strategy document, content inventory, site map, template page content and goals, use cases, wireframes, graphical comps, and style guide.
• The idea behind the two boldfaced entry comes from the idea that wording/content is important. This is not a new idea, but, according to Nica, that is a shift towards rediscovering it. It is the basis of a new book called “The Elements of Content Strategy“, available from ABookApart.com.
• Scenarios, uses cases, user profiles – these are all things I learned about, but never did. She did and emphasized their importance in the design process.
• New idea for me was to create a “greybox version of a wireframe“. Supposedly it is very easy to do in Fireworks and it acts as a mockup for the real site, but it is all greyscale. Useful to show it to the client as part of an earlier stage the delivery process.

The second and third sessions I attended were both about “Development best practices” and led by two Chapter Three employees:  Jenifer Lampton (director of training) and David Needham (themer and trainer). Both sessions covered two topics, so essentially I had these four mini-sessions.

1. Features module: The official description of the module is a good start but it doesn’t explain well enough what it can do: “The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.”
   – As I understood it “Features” is a way to pack together a lot of exportable parts of a Drupal site (e.g. certain views, menus, permissions, content types…) and export them as a “feature”, that can be used as is at another installation of the same site (e.g. dev, test, live) or possible at another site.
   – The example that was shown during the presentation was a photo gallery.
   – We used this site for the example.
   – During the QA I made notes to check out the Strongarm module (although the presenter disliked it.
   – Features is good for version control within the team and managing the lifecycle of one site. Not the best of using the exact same feature on sites of multiple clients.
2. GIT – “free & open source, distributed version control system”
   –  The notes for this part of the session can be downloaded from session’s description at the Chapter Three website.
   – This session was a bit over my head as I never used extensively any versioning system. The session was going fast, as we were running out of time, so I am not sure I followed everything. But I was told that I cannot mess up totally and will be easy if I start using it.
   –  Important to note that “commit” does not mean “push”: you have to “push” your files and changes to the server repository from your local/dev copy.
   – During the presentation I accidentally saw that the presenter is using http://www.fillerati.com/ a cool site to get  “filler” text content for sites under development.
3. Theming – I decided to attend this session as this one the areas that I need to learn now and am less comfortable with
   –  Theming is a system of overrides: base overrides core templates, sub theme overrides base theme’s templates.
   – It works like  “cascading template files”.
   – Base and sub theme can both go to sites/all/themes.
   – Each theme needs a .info file. In it name, core, engine, description, (base theme).
   – Drupal will scan the disk for a css. If it doesn’t exist it will not print the link to it in HTML. (smart)
4. Module writing
   – The most important lesson I took away from this session: “don’t be afraid.” The presenter assured us that once you get started with it you can do it; assuming you know PHP and how to look things up at http://api.drupal.org/api/drupal
   – Modules have cascading naming system. E.g. for blocks you have block.tplp.php (any block) ->  block-left.tpl.php (left side block) – > block-user.tpl.php (blocks showing up for users) -> block-user-1.tpl.php (first block showing up for users).
   – Every module needs a “.info” file with name, description, core, version, dependencies (if needed) and package (if we want to show up  in a particular section of the Modules admin page).
   – “.module” file starts with “<?php” but drupal will close this tag for you; you don’t have to.
   – Need to check Context module.
   – Do php things in code, not in the GUI, don’t put php code it through a text box in the GUI.
   – Don’t use the Contemplate module because it slows down things and it’s a security risk too.