Dec 9th, 2011 | Web Design | No Comments
I'm honored to have been selected to present at the first-ever DrupalCamp Michigan. The local Drupal community is super strong: they opened registration for 50 people and it sold out so quickly they expanded to 100. Not being a good public speaker at all, you'd think this might be daunting. However, a combination of under-preparedness and lack of sleep really put me in the right mindset. So, without further ado, here are the slides and a video of the presentation:
Notes
You've got the wrong guy
I originally proposed this session not because I have a ton of experience on the topic and all the answers, but because I wanted to use presenting as an excuse to learn about git.
If you've been using git for a long time and/or have memorized large portions of the Drupal APIs, chances are you won't be able to learn much from me.
WTF is a git!?
The word git was first a British slang word for an annoying or stupid person. The software was named self-deprecatingly from that word. I like to think git stands for something else though: good shit.
Git is a fast, distributed version control system.
It was originally developed by Linus Torvalds in 2005 to be used for developing the Linux kernel
If you've used another version control system, you might wonder what sets git apart.
From what I've gathered, the most important differences between git and other systems are:
- Git is distributed — this is important, because having a local copy of a repo lets you access the version history easily, commit whenever it makes sense, and push it to one or more repositories, or remotes, based on the structure of your project
- Git reduces the pain of merging, which means that you can make lots of branches without worry
Other systems, like CVS, subversion, and others, are also considered slow for accomplishing certain tasks. While I don't have a great means of comparison, git seems pretty quick to do most everything.
Drupal and Git
The Drupal project switched from CVS to git in February 2011. The changeover is a 3-phase process, of which they're on phase 2.
- Phase 1 was a git mirror, so that people could test and develop in git without affecting the project
- Phase 2 is a centralized model based entirely in git
- Phase 3 will be a decentralized, GitHub-like model that will change the Drupal.org contribution workflow. Details are still being hashed out on that front
Local Tools
Locally, there are a few tools that can make routine tasks fast and can integrate with the tools you already use.
I'm a visual, GUI guy, especially for menial tasks. So I like TortoiseGit on Windows, along with a Git plugin for Notepad++. TortoiseGit makes pushing changes a job of a few clicks. The Notepad++ plugin lets me press Ctrl+Alt+C, type a commit message, and click a button to commit changes to one or more files. If you think vi is a pain in the butt, tools like these are for you.
Remote Tools
It's probably not just you doing development. Even if it is, there's a compelling reason to have at least one central place for your repositories, which I'll explain later.
But a side reason to have bare remote repositories is that you can use tools intended for remotes, like redmine. Tools like this add another layer for project management. You can do project planning, bug tracking, wiki documentation, and other such tasks from a web interface, letting either you or your team keep track of things. And if your project is out in the open, you can leverage a much larger community using sites like GitHub, Google Code, or SourceForge.
Your First Repo
Let's say you have a directory of files that you want to put under version control at that path. You'd go there in your terminal, then initiate a new repository. Next you'd add all the files. Those files are queued up and ready for the first commit, which you then perform.
If you don't use the 'm' option to add a commit message, the commit command will show the log entry for the commit in vi, and you put the commit message at the top. It's at this point that I'd like to reiterate that vi is a pain in the butt.
So that's how you create a new repo from bash
Commands
These are the git commands you might use in day-to-day work
*Point at commands and explain what they do*
^ Learn what the commands do
These commands are used less frequently (in general), but it's good to know about them
bisect lets you determine where a bug began in the revision history, using a binary search to split the possibilities in half each time.
These are also git commands, though you might not use them very often or ever.
stash is commit for wusses
Workflow
So let's talk workflow.
At my job I've got two Drupal sites: "Beta," which isn't really the right name for it, since at times it's a dev box and at others it's a beta-slash-QA machine.
And the live site.
The design and development parts of my job revolve around creating modules and themes to add functionality and enhance the design of just those two properties.
I'm guessing that's NOT what your jobs are like. I'm guessing you make lots of sites. And those sites in various states exist in multiple places, like your local dev machine, an internal server for testing, and external hosting that you don't necessarily control. I don't envy you.
Wherein I Tell You Not To Hack the Core
A site is Drupal core, plus contrib, plus the data in your database.
Since Drupal is modular and nearly everything can be changed via hooks, it's really pretty rare that you have to change anything in core. And if you do, I've found from experience that it's usually for temporary debugging rather than for permanent changes.
Do not hack core.
Avoiding Temptation
So from Do Not Hack Core we can take away that all the things on the left are things you shouldn't mess with, and the thing on the right is the only place that customizations go (unless you have a weird multisite setup, which is cool, but your workflow's going to be different).
A repo at the whole site level is redundant, and reinforces the opposite of the number 1 best practice of the Drupal site-building community.
Drilling Down
What about at the 'sites' level?
This is workable, but you might notice something immediately.
Look at the sites/all/modules directory.
You're probably not going to be hacking contrib either! All of those modules are version tracked in git on the drupal.org site. The vast majority of those modules require zero coding to work exactly as expected. Putting them under version control doesn't accomplish much.
Then there's sites/default
sites/default/files contains uploaded and attached files. Those files are site-specific and are subject to database dependencies. The files also tend to be images and other files that are unlikely to change. There are a number of reasons why version controlling those files is impractical.
On the other hand, sites/default/settings.php is a good candidate for revision control individually, as it's something that you have to work on in the development process, and some of the settings will likely have to change depending on where the site lives. The branching model of git could be really useful for this purpose.
.gitignore Files
One way to wrangle sites/default/files and streamline the process is with .gitignore files. With a well-made, well-placed .gitignore file or two, you can continue using git add . and git commit -a without adding stuff you don't want to your project.
.gitignore files let you choose files to omit from the versioning index, based on wildcard notation. So instead of omitting /sites/default/files wholesale, for instance, you could just selectively ignore boring images and junk while preserving the directory structure wherever the repo might end up.
What You're Controlling
Conceptually, the two components that you're likely to work on that can most benefit from version control are:
- Customizing the theme to the client's needs
- Developing custom modules or modifying one or more contrib modules
If you start with a working theme, like Zen, you can clone down a repo from Drupal.org and use the history of that particular part of the project if you need it. You can create your own branch for your theme and develop from there.
If you code up a custom module, it might only be useful for a single site a single time. But maybe the functionality you add is something that other clients might want, or that can be contributed back to the Drupal community. Modules are reusable pieces, so structuring your repository environment to make them accessible for all sorts of projects is a plus.
Hypothetical Model
Here's an example of what repositories on a central server might look like.
I made the directory structure here very flat, putting core, modules, themes, and the site_projects repositories all within a single folder. This would work well if you always use the same base theme along with a limited number of custom modules. This particular setup plays nice with management software like redmine, which is one reason a flat structure is attractive.
If you're going to have lots of distinct themes and modules, it might be helpful to create big repos called modules and themes, then use git's submodules functionality to manage the individual drupal modules contained within. Thanks Ben for the submodules tip!
Now that we have a central place for all the things we're working on related to building our sites, we can optimize our workflow to play nice with version control.
Leveraging Synergy
One way to do that is to set up pushing and pulling.
If you don't already have ssh keys set up between your development box and your repository server, setting that up will make it a lot quicker to push and pull from git. If you want to deploy via git from the repo server to other machines like your site testing server or even live web server, you'll also want to set up ssh keys between the those boxes.
On your local dev box, use the clone command to make a local version of the repo on your server. When you do that, the source repo becomes a 'remote' called origin.
Make some changes to the local copy (you can branch if you want to, you can leave master behind). When you're done making changes and they're ready for other people in your shop to see/use them, use the push command to send them back to the origin.
Drush Make and Install Profiles
Once the changes are on the server, you can pull them to your deployment boxes, or...
You can get fancy.
It's a common use case: you end up using the same base theme, modules, configurations, and other tweaks on most of your projects. You might already have an "install profile" informally; Drupal with all the stuff you use all in one place.
The "drush make" command lets you generate makefiles that turn your informal install profiles into the real deal. In Drupal 7 it's easier to make profiles that configure things on install, but technically it should be possible in D6 too. Some combination of the features, strongarm, context, and other helper modules could let you automate some impressive stuff — like pre-built views.
Hint: it might be manual coding work, but if you install a whole bunch of similar sites, writing a [profile name].install file could be a time-saver in the long run. Especially if you swipe one from an existing public profile and suit it to your needs.
You can use the drush make command to import all the dependencies for your profile wherever you need them. Then just run the installer (which if you're super fancy you could get working with drush site-install) to have a functional site in the time it takes to make a pot of coffee because your junior dev doesn't know proper coffee machine etiquette.
The makefiles are really flexible, so you can choose particular version numbers of modules for compatibility, apply patch files to change modules or core code, or grab external libraries from tarballs.
Nailing down a "holy grail" workflow for this sort of development takes time and effort, and I certainly don't have all the answers.
Over the next few weeks, Alex Fisher and I will be working on drush make and workflows, and will report useful findings to our respective blogs.
You may also ask about how to go from local dev to testing to quality assurance to live, all while easily managing your databases. You may ask that, but I don't have an answer. Sorry.
Pay it Forward
If you'd like to become a core developer or get involved in a contrib project, a working knowledge of git will help.
I'm fighting the urge to give nitty-gritty details here, as the instructions are both technical and well-documented. If you're not a project maintainer, contributing code involves creating patch files based on numbers from the issue queue. If you are a project maintainer, you can interact directly with the remote repo (albeit while following the guidelines).
One reason I'm avoiding an in-depth explanation is that the Phase 3 git migration could very well change how things get developed on Drupal.org.
But here's how to create a patch file, just in case.
Just one commit is the easiest for contributing back patches.
The Version Control tab on project pages gives really good instructions for grabbing source repos and other contibution tasks, including the specific clone command you need to grab a local copy of the repository.
So now that you're a git expert, go out there and contribute back to the Drupal community!
Thanks for putting up with me!
Apr 27th, 2011 | General, Web Design | 4 Comments
Chris Coyier posted a nice, working solution to a real problem over at CSS-Tricks. Basically, CSS lets you style your website to look and work well on mobile devices by over-writing the styles of your full-size website. There are performance drawbacks to this approach, but for the most part it's the best-of-all-possible-worlds solution.
One thorny problem, though, is over-riding the style of certain elements that use the width of the screen liberally by default. One such element is the venerable data table.
Coyier's solution is great in that each table cell is labeled. However, doing this requires either writing CSS manually for every data table on the site (which is near-impossible for large sites) or having the same thing done with scripting on either the server or client side:
I propose a generalized solution that requires no scripting whatsoever. The drawback of this method, though, is that the cells are not individually labeled. The example is also more compact, but this aspect can be tweaked by marrying the two methods:
@media screen and (max-width:720px){
table{display:block;}
td,thead th{border-color:#444;border-style:solid;border-width:0 2px 0 0;display:inline;float:left;}
td:last-child,th:last-child{border-right:0 none;}
thead th{background:transparent;font-size:1.1em;}
tr{display:block;float:left;clear:left;padding:6px 0;width:100%;}
thead tr{border-bottom:4px solid #444;margin:0 0 .3em 0;padding:0 0 .2em 0;}
tbody tr:nth-child(even){background:#ddd;}
td:nth-child(5n+1),th:nth-child(5n+1){background:#FFD8D8;}
td:nth-child(5n+2),th:nth-child(5n+2){background:#FFE8D8;}
td:nth-child(5n+3),th:nth-child(5n+3){background:#FFF8D8;}
td:nth-child(5n+4),th:nth-child(5n+4){background:#D8FFD8;}
td:nth-child(5n+5),th:nth-child(5n+5){background:#D8D8FF;}
}
Open the working demo and resize your window to under 720 pixels wide to see the effect. I call this approach the "Rainbow Tables" method 
Thanks to Chris Coyier for posting a thoughtful working solution, and thereby motivating me to post about my approach after sitting on it (in production no less!) for almost a year.
Mar 3rd, 2011 | Libraries, Web Design | 3 Comments
I'd like to touch briefly on a widely-circulated LJ post by Aaron Schmidt entitled Resist That Redesign. It is generally good advice – using iterative website design rather than relying on complete redesigns. However, I think the advice needs better context.
For one thing, most library websites are really outdated and bad. Comparing the design/development workflows of Apple and Google (nice!) or Amazon and Netflix (not exactly gems of design) to how libraries maintain their sites is apples-to-oranges. If a library has a flat-file website (Not a straw man: this is common in libraries!), performing a complete redesign/redevelopment is probably advisable. A "slowly evolved" CMS developed in-house at a library is likely to be slapdash, and there are tons of available CMSes that are well-designed, secure, free, and supported.
What's not mentioned in the original post is that redesigns don't have to be long, painstaking processes. Bad redesign processes are that way, but a sufficiently-experienced and talented designer can ease those woes. The solution for doing a good redesign is to have a good designer.
Likewise, iterative design isn't always a breezy process, and it often isn't design. Design needs control; website creative control is often lacking in library environments. What often ends up happening under the guise of "iterative design" is actually a patchwork; sometimes from having too many cooks in the kitchen, sometimes from having one crummy cook. We've all seen these websites; they start out clean and freshly-designed. Then someone pastes in a widget and it clashes with the design. Then comes more widgets ad nauseum until the site looks and works awful. As such, the solution for doing good iterative design is to have a good designer.
Library folks: don't resist redesigns. If a well-designed website is important to you, hire a good web designer. Trust their judgment to decide whether the best course of action is to iteratively improve your site or to do a full redesign.
Jun 23rd, 2010 | Web Design | 1 Comment
Here are the slides and notes from my June 16th presentation for Refresh Detroit. I was fortunate enough to be joined by Alex Fisher and Stephen Colson, who really brought everything together and luckily had all the answers. Thanks again, guys.
The following notes do not reflect the actual presentation. If video evidence comes along to prove this, I will add it to the bottom of the post.
Slide 1 - Welcome
Hey, I'm Brad Czerniak. I'm the web guy at Canton Public Library.
Thank you very much for coming to see this presentation today. And especially thank you to Deborah, for inviting us to speak. I hope that what we're talking about will be useful.
My presentation is decidedly impractical - I'm gonna try to explain what Drupal is and some of how it works.
I'll be followed by two really energetic and talented guys: Alex Fisher from Commercial Progression, and Stephen Colson from Switchback CMS. They will put the rest of the puzzle together with real world sites and practical demos.
Before moving on, I'd like to thank all the people who contributed to this crowdsourced presentation, and all the local Drupal user groups for their support and advice.
Slide 2 - Drupal is a free & open source content management system the answer
So, right off the bat:
Drupal is free and open source. It's released under the GNU Public License, which is the same license used for the Linux kernel and around 60% of open source software.
You may have heard of LAMP. I love lamp. It stands for
While Drupal could be considered a typical LAMP application, you should note that only the P is strictly necessary. It can run on Windows or Mac, with various web servers, and with a few different database systems. It is written in the PHP programming language, so you're kinda stuck with that requirement.
It's been around for nearly 10 years and a whole new version is set to be released soon.
Drupal is the answer, but what's the question?:
- Do you want a powerful website?
- Do you want to add more features later?
- Do you need support?
- Do you want different users to do different stuff?
- Do you want options? There's an easy way and a hard way for everything in Drupal*
I have to admit something now.
Slide 3 - Drupal kinda sucks (right out of the box)
If I have learned anything in the last two years, it's that Drupal is not a Ronco Showtime Rotisserie
It's not "Set it and forget it"
This out-of-the-box unimpressiveness is by design, though. The use case for Drupal is for a site more sophisticated than a small personal blog. It's assumed that you'll customize the site to some degree before unleashing it on the public. It's not strictly necessary, but a site based on a basic Drupal install won't turn any heads.
Drupal also has a notorious learning curve, partly due to an administrative interface that tends to scare away beginners. Luckily, one of the big features for the upcoming version is a big improvement in usability.
Let's take a look at what you get out of the box.
Slide 4 - Your New Site
It's like this.
A blue-and-gray theme called "Garland" is set by default, and you have two content types - page and story.
If you install Drupal for the first time, this can be an incredibly scary sight.
Content types are important: They range from "blog post" to page to a form to external content from RSS feeds to whatever you can dream up. Each content type has a bunch of options:
- Whether or not you want them to take user comments
- Which users you want to be able to create, edit, or delete content of that type
- Whether you want new posts of that type to show up on the homepage
Stuff like that. You can set all of that on your website if you're an administrator. No coding necessary. Once you get the hang of it, It's really easy and flexible.
Slide 5 - The Happy Middle
And it's that flexibility and ability to do complex things without code that sets Drupal apart from other solutions.
Here on the left we have Rails, Django, and CodeIgniter. The basic idea behind all three of them is that they're frameworks - tools for building web applications that help you do it quicker than starting from scratch and using some basic guidelines to make sure they don't suck.
But, when you install them, you have to write code before you even have a basic webpage.
On the right we have WordPress and MediaWiki. WordPress powers almost every personal blog on the web. It has like 200 million installs.
MediaWiki is the software that powers Wikipedia and a ton of other sites.
When you install them you're up and running. You don't need to worry about the particulars - just add content. These applications are great if you want a blog or a wiki, but they take a lot of work and aren't really intended to do much custom stuff with them.
Drupal sits in the middle. It gives you the flexibility of coding a site yourself and the beginnings of common website use cases right when you install it.
Slide 6 - Sweet, Sweet Nodes
So that's sweet, right?
One of the scary words that's really important to understanding Drupal and talking shop with other Drupalistas is 'node.'
A node is an individual page or blog post or whatever you've dreamed up.
All the real content of your site is made up of nodes. Everything is a node.
Node node node.
It might help to think of a node as a note. Or it might not. But a note or a memo has a subject line or title and some content. All Drupal nodes have those things too.
If you want to organize your notes you might put them in folders or attach Post-Its to them. This is kind of how Taxonomy works.
Taxonomy is another one of the scary words.
Here's the skinny. A taxonomy is a list of descriptive terms. Each term is like one tag in a tag cloud. You can stick these tags to any node and use them to organize your content.
Down here we have the tape dispenser, labeled CCK. That stands for Content Construction Kit. I'll talk about Modules in the next slide and Steve will demonstrate CCK specifically, but the general idea is that CCK lets you attach all kinds of funky things to your notes - like photos and even whole other notes.
Slide 7 - Modulez, Drupal Enhancement
There are 5703 total modules. That's a lot.
A module extends (extenze, get it?) what Drupal does. In fact, Drupal is made up almost entirely of modules. Each one performs some small role.
So there's a module called node that does stuff for the nodes from the last slide.
There's a module called menu. Confusingly, it mostly has to do with URLs, but kinda not really. It's one of the things you only have to learn at 1:00AM on a weekend while wired on Mountain Dew. So we'll skip over that for now.
Those are modules that come pre-packed when you download Drupal core.
Then there (contributed) modules nicknamed contrib modules. These are written by the community to make Drupal awesomer.
CCK from the last slide is a contrib module lets you add more stuff to your nodes.
Pathauto lets you make friendly URLs with tons of options
Rules lets make things happen on your site. It's a good example of the "easy way" of working in Drupal.
There are modules to give you fancy calendars, Word-like rich text editors, and 5700 other cool things.
Slide 8 - Umbday Exampleway
So here's a rich text editor. You can pick which one you want to use from a bunch of different cool options, then install the module and set it up.
Boom! Now you have WYSIWYG capability. And you have options, just like the Drupal gods intended.
Here in the text box we have some pig latin. If you aren't fluent, it says "This is a really dumb example."
It's a dumb example because --
Well... let's say you want to make a node and you want that node to appear in pig latin to your users.
You can type it out in plain English and let Drupal do the translation for you.
There are many modules that let you type in wiki syntax or markdown or plain URLs or ISBN numbers and the module turns it into something cool for your users when they view the page. At the library, for instance, we use double square brackets and links to books in our catalog to import book cover images and the title and author and stuff. This is a real time saver and it's all automatic.
And you can mix and match these filters. If you want to strip out certain html tags from the text AND put the text in Pirate-speak, no problem!
This particular example is dumb because when you're creating or editing that node, you'd just see English. So silly.
Drupal also has non-ridiculous translation built right in. You can put your menus and other site text in other languages and switch it for different users and all kinds of stuff. If that's an important part of your project then you'll be stumbling into a funky corner of Drupal's learning curve.
Slide 9 - Users
One of the most powerful features of Drupal lies with User management.
Out of the box it handles sessions and cookies and usernames and passwords and all the stuff that's a big pain in the butt to get right yourself.
On top of that, you can assign permissions to users in a really common sense way.
You can create roles. Roles are containers for much more specific permissions. An example of a permission is "User can edit their own blog posts."
So an admin is free to do anything on the site. A signed-in user can do some things, but is restricted depending on what roles on the site they've been assigned.
A visitor CAN have permissions, but generally can just view stuff through their binoculars.
When you install modules, they often give you new permissions that you can assign, so it's really easy to make sure that the right people can see and do the right things.
Slide 10 - API
This ability for modules to tie into what Drupal does is because of the API.
API stands for Application Programming Interface. It's the way that programmers can interact with the code and data in an application.
Drupal's API is full of these things called hooks. These hooks let you add stuff to Drupal in a standard way.
For instance, when writing a module you might want to use hook_user. Your code might say - when a user signs in, redirect them to a different page.
When one things happens, do other stuff.
Once you get the hang of it, writing code for Drupal makes a lot of sense.
Slide 11 - Page Theming
Along with coding modules, you can also code themes.
You can hard-code HTML into your theme, or put little bits of PHP in there to display the content from the database exactly how you want it.
If you use the default template language, called PHPTemplate, you can specify regions on your page to hold blocks of dynamic content stored in your database.
You can move these blocks around from your browser. Once your theme is coded it's really easy to put stuff where you want it.
Your theme consists of a bunch of template files. This one is for an entire page.
Slide 12 - Node Theming
This one is for a single node. A page can have more than one node displayed at a time, and those nodes can be of many different content types.
Does that make any sense?
Think of a bag of jelly beans. The page itself is like the bag. It wraps around all the good stuff.
Each node is like a jelly bean. All the buttered popcorn flavored beans are from the product content type.
But the bag also has black licorice beans. These could be wiki entries.
The one page could show products and wiki entries in one listing.
And the cool part is that you can make them display however you'd like using template files.
This doesn't speak to how gross a bag of popcorn and licorice jelly beans would be, but this is America so you're free to fill that bag however you'd like.
Slide 13 - jQuery is Money
Nothing's better than esoteric programming double entendres.
If you know jQuery, you know that the shorthand for the base function is the dollar sign.
But I also mean that jQuery is money. jQuery is so money and it doesn't even know it!
jQuery is baked in to Drupal's core. You can even code up your JavaScript is a very Drupal-ish way using Drupal's concepts of behaviors, settings, and locales.
But that's not all!
You can use all the same web standards that everyone else uses, or go your own way.
If you want to use a particular CSS Framework, there's probably a pre-existing theme to do it, or you can roll your own.
If you want to do everything in HTML5, Drupal won't complain.
If you want some visitors of your site to view your pages in full size and others to get a mobile page, that's very doable.
Drupal lets you do what you already know and gets out of your way.
Slide 14 - All the cool kids are doing it
What else can I say to convince you that Drupal will work for your site at the scale you need?
Argumentum ad Populum. Translated from the Latin it means "All the cool kids are doing it."
There are a lot more prominent sites and organizations using Drupal, but these sites are notable because you're in Drupal when you get to the home page and most if not all of the content is in Drupal.
That's a powerful indication of the trust organizations place in Drupal and the ability of it to suit complex needs.
Slide 15 - Support
Another great selling point is the available support.
You can get help directly from the Community via IRC, Forums,and other avenues.
You can get materials ranging from books to videos and more from Lullabot, Apress, and other publishers
The creator of Drupal has a company called Acquia that also lends support.
The documentation for every aspect of Drupal is amazing. If you want a quick how-to for a beginner it's on the Drupal site. If you need in-depth documentation of the API, it's there too.
Each module has an issue queue. These are really handy for seeing if the issue you run into is a known bug or a picnic error.
Most any problem you run in to likely has a forum post or page on the Drupal site. The site search is arguably the best tool for getting the support you need.
There are also plentiful user and developer groups. There are at least three in Metro Detroit.
You can also hire a firm to develop, design, consult, or for individual bounties to develop a particular feature.
Options. Drupal gives you options.
One more thing...
Slide 16 - One More Thing... (Views)
Views makes a Developer's life so much easier.
I'm not ashamed to admit that I frequently take the lazy route. Views is the lazy route in a very real and very cool way.
Remember the jelly beans? Let's say all the content on your site is a big tub of jelly beans.
Views lets you put whichever beans from the tub you want in whichever bag you want.
If you want an RSS feed with just the images from your products in order by the date they were last edited, you can do that by playing around in Views for a couple minutes.
If you want a block in the sidebar with the latest posts from one user's blog, that's a cinch.
If you want a page of all the posts tagged chicken in reverse-title order, you can do that.
With Views. Views is a miracle wrapped in a magic trick.
Views makes learning Drupal SO worth it.
Jan 17th, 2009 | Web Design | 2 Comments
You're like me: you use your iPhone as an alarm clock. You even cued up Sonny & Cher's "I Got You Babe" to play just like in Groundhog Day (to remind yourself every morning that the only way to beat the futility of day-to-day life is to strive for what you really want).
Yeah, you're like me. So I'm going to assume these things are true too:
- When you wake up, the lights are off and your eyes have been closed for 4-12 hours
- You've kind of enjoyed being asleep, and are kinda cranky at whatever's making that racket
- When I say cranky, I mean your judgment may be a little impaired too
What am I getting at here? The iPhone alarm clock is really usable -- it's easy to set, fairly customizable, can schedule alarms really well, and is reliable as it gets. The only time that the usability sucks is when you're just waking up. Here's what it looks like when the alarm goes off:
Here are the problems with this in my opinion:
- It uses your default wallpaper, which could be blindingly bright with undilated pupils and other changes to the eye that occur in low-light conditions
- The text is small, condensed, and white, making it hard to read because optical resolution is lower at low-light conditions, and the brightness of the letters makes halos around each one
- The snooze button is small, and fumbling around for it can be very frustrating
- On an older-fashioned alarm clock, you don't actually read the word "Snooze" when you hit the button -- it's just the big button on top. Reading the word makes you mentally connect-the-dots. Call me weird, but sometimes when I wake up and read the word Snooze on the phone I think I'm in some Dr. Seuss-esque dream
So I propose an interface more like this:
An Apple designer could make it prettier, but the basic ideas are there. The background is black, all elements are - at brightest - 74% gray, the Snooze button is about twice as large, and it says Sleep instead of Snooze. Also, it doesn't really break from the core iPhone UI; the same slider bar, clock, top bar, and dialog colors are all present (though I used black text in the button for contrast's sake).
If you'd like to know more about human vision in low-light conditions, check out these Wikipedia articles for starters: Rod cell, Scotopic vision, Adaptation (eye). Also, for some User Interface advice, knowing about Fitts' law could be really handy.
It would also be great if there were an easy indicator to know when it's in Snooze mode. I often set a second alarm because I'm not sure, so then there are two alarms going concurrently. Then, as I finish checking my email and Facebook, a little dialog shows up and I hear that damned song again. How about putting the number of Snooze minutes left inside of the alarm indicator in the top bar? Thanks.
Mar 9th, 2008 | General, Web Design | No Comments
My resume is finally ready for the web. However, I'm interested in your opinion and criticism, so please contact me with your thoughts.
Also, for your time-wasting pleasure, I give you: Faker Baker BS3 . Anyone's who's ever used B&T knows this screen all too well. Now, all you have to do is point your browser to brad.hawidu.com/bt and you'll instantly look busy! For you pros out there, the color is #47768e.
Feb 15th, 2008 | Web Design | No Comments
www.isitoppositeday.com
My parody of the famous http://www.isitchristmas.com/ website.
IS it Opposite Day? Think about it.
Dec 24th, 2007 | Web Design | 5 Comments
Hey everybody. I hope that my relentless testing this afternoon didn't bog down your aggregator. Anyways, I made a little gadget that communicates to independently-hosted blogs via xml-rpc. You can read all about it here, and also add it. Hope SOMEBODY besides me finds it useful. Oh, and all the source is available at that link too. Enjoy!
Jul 5th, 2007 | Facebook, Web Design | No Comments
Okay, so it's been about four days since the application launched (btw, I swear there will be non-application blog posts someday!), and things are going overwhelmingly well. I've gotten a lot of feedback, mostly positive. My upgrade schedule is pretty-well set, but I'm looking to see if people would do things in a different order:
- Get the digg-like interface for resources up and running. This will allow anyone to contribute to the resources, vote on them, and add comments. The top five will be displayed on the "canvas page," with a link to the full listing. The universal resources will still be at the top (probably), but any catalog, database, etc. can be added.
- The profile badge will have the newest and/or recently popular resources instead of the (hilarious) video from Weird Al's movie, UHF.
- An additional section will be added that will link to an Information Literacy wiki (If a good one aimed at non-librarians already exists, please link to it in the comments) in colloquial language to help patrons help themselves.
- Some sort of usage of the invite notification system provided by Facebook. This will be aimed at getting users. As expected, the initial users of the application have (mostly) been librarians. This is positive for a few reasons, and useful because the infrastructure is there for patrons with Facebook-based questions.
- Tweak my database of librarians with additional email addresses, homepage URLs, and other useful data – currently-registered librarians can easily update, while new librarians will automatically have the option.
- More stuff is on the way, especially since the feedback and suggestions have been wonderful!
Note: I get off work today at 9:00PM, and will be burning some hardcore midnight oil to get these launched as quickly as possible. Please be patient as things come into operation over the weekend. Thanks!
You can see what I'm up to by adding the alpha app – http://apps.facebook.com/fblibrariantest/
Also, look out for the open Application Data, and eventually the open source.
(Lastly, on a personal note – My packrat mentality makes it insanely difficult to weed "my" collection. Just wanted to get that off my chest.)
Jun 21st, 2007 | Web Design | No Comments
Let me start with the bottom line: You should make a widget for your site. It should:
- be very lightweight in terms of images and text content.
- have the most useful and original aspects of your site included.
- create incentive to click over to the full site
- follow one of the most-common (netvibes, iGoogle) form factors
- be standards-compliant XHTML
What!? XHTML? The common view of widgets and gadgets are the XML + AJAX + web 2.0 whatevers that you find all over the place. I know Google supports URL-specific gadgets -- not to mention that the code you copy and paste into the XML is HTML for the formatting anyways.
It should be XHTML because the gadget can then easily double as a site for mobile users -- a growing segment of the online population. Pish-posh to iPhone Safari and Opera 4 Mobile – The screens are still small – so the content should be as well.
Outside users can embed it in an iframe, and the basic structure can be ported into almost any site that uses gadgets natively. This opens up the possibilities to a much wider range of web publishers – including novice users.
The thing that appeals to me the most about widgets is that they consolidate content even more than websites have in the past. A well-made widget puts the best dynamic content from a given site in a format that can be splattered all over the internet like leaflets.
Oh, and geniuses -- why hasn't anyone put AdSense in the minimessages library of GooGads yet?
