Thu, 1 Dec, 2011
Next Saturday, December 10, I will be presenting on responsive accessibility in Drupal at DrupalCamp Chicago 2011. Check it out:
- My session - Using Drupal for Responsive Accessibility and Design
- Full session schedule
- DrupalCamp Chicago website
DrupalCamp Chicago is a fun, collaborative for learning and brainstorming about Drupal, and even developing for Drupal. Users, editors, site builders, themers, and developers alike come together to discuss new developments and tutorials for creating awesome Drupal sites. Hope to see you there!
Thu, 10 Nov, 2011
Web accessibility is a great thing, and a necessity as the web advances with newer and better technology, with more and more content made available widely on the web.
But, more to the point, we can all agree on that. Web accessibility is a tough subject to teach, but it is a more necessary subject to teach than almost any other web-related subject. Interested developers can look up literature in print or online to learn about pretty much any other subject and get a good grip on it, and while the same might be said for certain areas of web accessibility, it cannot be said of web accessibility as a whole. It is a subject about people, and personal to every user we aim to help. I have never met web developers more passionate about their work than web accessibility advocates, and I include myself in this group.
However, web accessibility is still struggling to be understood and more importantly, adopted by the majority of web developers. There are any number of reasons to comprehensively define why this is, but I’ve come to learn through my own experience as an accessibility educator and researcher that there are several things that we as advocates must be careful to avoid doing. These are all too easy to do, and can actually hurt our ability to share our knowledge with non-accessibility-minded developers who are interested to learn.
5. We assume that others don't know anything.
Let's say that you know a bit about mobile development, and want to learn enough to start incorporating it into your work, so you pick up an article that promises to help you get a handle on the subject...and the first 3 sections are about how mobile development is for screens that are tiny.
Even if your audience knows nothing of web accessibility, most of them likely know at least a thing or two about web and/or content development, and can infer much of the most basic web accessibility information (for example, that invalid HTML markup makes screen readers speak in tongues) based on the rest of your quality research data and information. There’s no need to reinvent the wheel each time you bring up web accessibility techniques.
It’s useful to sometimes consider your audience as you would a classroom of students. Just as students will likely glaze over if you start to monologue about things that they already know, so will your audience. A good way around this is to encourage active learning through active participation. Before reciting the explanation of “What ALT text is” for the hundredth time, assume that your audience is likely acquainted with that concept. Ask for a quick show of hands if you’re not sure. Have all of these basic explanations in your reserve in case someone in your audience actually needs you to explain them, but unless someone does, don’t worry about including it up front.
A really great way around this problem was done by a colleague of mine, Dan Allen at Drexel University. Dan presented a 45-minute Basics of Accessibility lunchtime brown bag. When introducing the challenges faced by disabled users, he started with an overview of commonly-used assistive technologies--and that was it. By explaining what a mouth stick is and how it’s used, he was allowing his audience to figure out for themselves what some bad design choices could mean for a person using one. This not only prevents you from losing your audience, but will also make the experience of learning about web accessibility far more personal for each person there.
4. We assume that others know too much.
If you have digested more than one presentation or article about web accessibility, you know that ALT text and header tags are the Golden Oldies of accessibility education. This is with good reason--if developers do nothing else, this is a quick, easy way to get some baseline accessibility in place for many assistive technologies. It is also one of the easiest concepts to get across in the limited time of a conference presentation.
One of the biggest problems for web accessibility’s complete incorporation into the majority of the web is the steep learning curve that comes with really getting involved in active development. The WCAG 2.0 documents are notoriously dismissed as long and hard to grasp, understandably, and especially for people who have no real background in web accessibility. Something that may be obvious to a web accessibility advocate, or a person who’s done even a moderate amount of research on web accessibility, may completely go over the head of a person just learning these concepts.
It is often a good idea to limit the amount of information covered in a presentation on accessibility. It is a hard transition for beginners to go from understanding the basic challenges for assistive technology users, to figuring out the best way to incorporate aria-live regions into their Javascript-based feed display areas.
That’s not to say that we should dumb down the content--far from it. A narrower focus for a presentation gives you the opportunity to really delve into that subject, and give the audience lots of information and opportunities to understand. It is also helpful to relate advanced concepts back to earlier-introduced concepts. One thing that I often find helpful is relating a programmatic solution back to a specific web accessibility challenge, allowing the audience to relate the concept back to their own mental image of the challenges posed, and also once again driving home the basic concept that, at its root, web accessibility is about people.
3. We get hung up on one cause of accessibility.
I’ve noticed something--when it comes to advocating specific practices, many web accessibility advocates tend to focus on advocating for the best user experience for one or two types of disability or assistive technology. It doesn’t happen maliciously--maybe the developer has a friend or loved one who uses a specific AT or uses it him/herself, which makes the cause more personal to him/her. Maybe the developer has specific programming skills that can make the user experience awesome in that particular situation. These are good reasons to teach about that particular branch of accessibility, to be sure, but when taking up a position in an article or presentation as educators on web accessibility as a whole, we can’t forget about the wider cause.
Referring back to #4, stressing web accessibility on the whole as a concept and then pointing out problems and solutions for just, say, screen readers is assuming too much of the audience. It often gives the appearance that just this one type of action really needs to be taken, particularly by developers who are new to accessibility, and/or may be looking for ways to quickly incorporate it into their daily development and existing projects.
If, for instance, you are teaching just about screen reader accessibility, this should be made clear in your materials, your presentation title, and your instruction style; make it clear that this is in no way a comprehensive look at web accessibility, but rather a comprehensive look at this specific problem. If possible, try pointing your students at comprehensive sources like WebAIM or WebAxe to learn about more areas of accessibility. Also consider co-presenting or co-teaching with another accessibility advocate who has a passion for a different avenue of accessibility in practice.
2. We try to convert people who don't need converting.
I always think it’s a shame when I read complaints from accessibility advocates on Twitter about how they wished some presentation they saw or article they read had delved more into the guts of web accessibility, rather than focusing on “why web accessibility is important.” It’s a wasted opportunity when we get a room full of accessibility advocates together and end up rehashing the same old stuff.
It's like going to the movies, buying a ticket, and the first 20 minutes of the film is just the actors trying to convince you that the movie you're about to see is actually really good and you should definitely stay and watch the whole thing. The fact that you showed up implies that you're already planning to do that. If it's good, of course you'll stay, and if it's dreadful, you'll still walk out, no matter how hard a sell you got at the beginning. The film speaks for itself in terms of quality, and the same should be said of accessibility presentations to accessibility-minded people.
And chances are good that if you are giving a talk about accessibility, there will be accessibility-minded people in the audience, hopefully many thousands of them because that is just how cool this subject is. They may not know everything you’re going to say (hopefully not in fact, if you’re doing it right :)), but one thing you should not have to worry about doing is convincing them that web accessibility is something worth incorporating into their sites.
I can’t think of many other web development topics that so consistently feature a justification of the topic before actually beginning the presentation or article than web accessibility, and this is dangerous. It puts us as the advocates into a defensive position right off the bat, and this is unnecessary, at least in this situation.
The fact that web accessibility is important because it opens the web up to all users and provides a fair experience for all (whoops, there I go) is something that absolute beginners have to learn about web accessibility, not developers with even a nascent interest in the subject. As such, unless you are giving a talk or writing an article that is akin to a beginner’s guide to web accessibility, you don’t necessarily have to restate this opinion unless prompted, wasting precise time, slides, or word-count-limited characters on something that your audience already knows. The importance of why we are doing this should reflect in the rest of your instruction materials, and your true passion for the subject matter.
1. We blame people for not already knowing.
A few days ago, I accompanied my mother to a restaurant to book a private event. We told the hostess it would be for a small group of people--about 20. She asked anxiously if anyone in our party was in a wheelchair or had any sort of ambulatory problems. She asked this because, as she then pointed out, the section of the restaurant reserved for private events was on a raised platform, with two steps leading up to it. She’d had a party come the month before and to her surprise, one of the ladies was in a wheelchair. The hostess hadn’t even thought to ask; she hadn’t thought anyone might have a problem getting up there.
I’m sure that most of us have at least a few anecdotes like this; examples of non-disabled restaurant hosts, shopkeepers, secretaries, and web developers providing an inadequate or unusable product or experience for a disabled person, because they didn’t even know there was a problem. In some of these situations, they may have thought there was a solution in place (as in some of the cases described here), or had a reporting mechanism that went unused. In others, they may have just honestly never had to consider accessibility. But in none of these situations should these people be vilified for their ignorance to the problem.
In this environment, web developers who make accessibility mistakes become scapegoats rather than people who can help fix a problem. Opportunities to learn become opportunities to scoff and blame. Developers who are eager to learn and help become nervous and ashamed of the work they’ve done, and afraid to ask a question for fear of it exposing them as not being an accessibility expert.
It’s always more desirable to assume the best of people in this situation. Rather than treating a mistake as if it was done out of carelessness or maliciousness, realize that you as an accessibility advocate and specialist have a gift that you can share. We should take every web accessibility bug we encounter as an opportunity to teach in a respectful way. If a private request (meaning, not as a public tweet or Facebook status update) for a fix or offer to help goes repeatedly ignored, then it’s of course reasonable to feel that it isn’t being treated with the importance that it needs to be.
Realize, also, that fixes take time. That restaurant my mother and I went to didn't yet have an accessibility solution in place for their party room, but they are working on installing one, and in the mean time, they're making sure to find accessible party spaces within the building. While everyone should be incorporating accessibility measures from the get-go on development projects, it still doesn’t often happen that way. Many developers who are beginners in accessibility are not beginners in development, and have tons of already-released projects that work beautifully...until they apply the principles of web accessibility. If they want to fix them, we should help, and in such a way that doesn’t make them feel sorry for even trying. Rather than grumbling about how the resources out there are too basic and many developers don't understand web accessibility, get out there and help someone!
I’m going to lift this bit of this straight from my presentation, Advanced Accessibility in Drupal:
"If a developer wants or needs to learn about accessibility, and if we take up a position of education in the open source community, then we have a duty to help those who want to learn.
Particularly when a student is learning something because he or she is afraid not to know, a culture can emerge in which the student is afraid to ask, and therefore reveal that he doesn't know."
By no means do I consider myself the absolute expert on this subject, nor do I intend to dictate any standards here; these are just some thoughts that I hope will provoke some good ideas and discussion among us. We all know that accessibility education is for everyone; we have the tools to teach. Let us all realize that we are in a uniquely helpful position to make the web a better place.
Wed, 4 May, 2011
Zen is a terrific project out of Drupal.org, written by the extremely talented John Albin. There are a lot of things that are highly configurable about implementing a Zen subtheme.
An important part of any theme is its cross-browser compatibility. For most browsers, this isn't a problem, but a need for this type of compliance makes it so that conditional stylesheets are almost always needed for Internet Explorer; the more versions, the more stylesheets (often enough, anyway).
When you create and implement a Zen subtheme, a quick trip through your live page's source will likely show the following:
<!--[if IE]> <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/zen/zen/ie.css?C" /> <![endif]-->
This is no big deal generally, but it can be bothersome if you want to start calling your own IE stylesheets. If you want to add some version-specific IE stylesheets, simply add the following to your subtheme's .info file (see the comments--which are unnecessary in your own .info file--for when each line appears):
; Anything below IE9 conditional-stylesheets[if lt IE 9][all][] = ie7-and-8.css ; IE7 browsers only conditional-stylesheets[if IE 7][all][] = ie7-only.css ; IE6 browsers and below. This will also be affected by ie7-and-8.css according to this syntax. conditional-stylesheets[if lt IE 7][all][] = ie6.css
The second set of brackets is for media queries, so you can specify further there too, I just put "all" in for this example.
After you add this to your .info file AND rebuild your theme registry, you should view something like this in source:
<!--[if IE]> <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/zen/zen/ie.css?9" /> <![endif]--> <!--[if lt IE 9]> <link type="text/css" rel="stylesheet" media="text/css" href="/sites/all/themes/MY_THEME/ie7-and-8.css?9" /> <![endif]--> <!--[if IE 7]> <link type="text/css" rel="stylesheet" media="text/css" href="/sites/all/themes/MY_THEME/ie7-only.css?9" /> <![endif]--> <!--[if lt IE 7]> <link type="text/css" rel="stylesheet" media="text/css" href="/sites/all/themes/MY_THEME/ie6.css?9" /> <![endif]-->
Please note, YOU MUST PUT THE ACTUAL CSS FILE INTO YOUR THEME'S MAIN DIRECTORY IN ORDER FOR THIS TO WORK. If you just put the conditional stylesheet reference into your directory and try to make this show up before you actually start adding to your CSS file, the conditions won't show up in the header. They will show up once you add the file. You'd be surprised how many times I've witnessed someone get hung up on this particular aspect.
Now this is well and good, but you'll see that Zen's ie.css is still being conditionally called here. Again, not really a problem as it's only used for good, but if you want to override/remove this, go into your subtheme's .info file again and change this line:
; conditional-stylesheets[if IE][all][] = ie.css
to this:
conditional-stylesheets[if IE][all][] = ie.css
That is to say, uncomment it.
If you want to override the file, place your own ie.css file into your subtheme's main directory, filled with all of your own IE-fixy goodness. If you'd prefer not to call this stylesheet from the Zen theme directory, after uncommenting that line, do not put a file called ie.css into your subtheme's directory. Once again, if a stylesheet does not exist in your subtheme's directory, the theme engine is not going to waste time setting up a condition for it, so if it's gone from your directory, it's gone from your overhead.
As April 2011, IE6 makes up 2.5% of the browser market, and if you're still working with it, I'll assume it's part of your company's baseline for some weird reason, or you're some kind of programming masochist. IE7 makes up less than 5%, but is still often programmed for in larger institutions, as small parts of big numbers are still pretty big numbers. Being able to discard the need to program for IE6 already means a lot less overhead, but IE7 still introduces a host of problems, as does IE8. IE9 promises to implement a lot more CSS3 and adhere to a lot of web standards, but even right now, requires special stylings. Keep this in mind when writing your Zen subthemes!
Wed, 20 Apr, 2011
I was fortunate enough to score a seat in the discussion at a workshop at the University of Delaware in Newark, DE this weekend. The focus was "Social Media, Online Collections Tools and Small Museums," and it was put on as part of the Sustaining Things series by Hillary Mohaupt and Kate Duffy, both of whom work and study in the Museum Studies Department at UD.
The topics covered applied not just to museums, but also to libraries, archives, and higher ed institutions. Rather than trying to cram in mention of every single social media tool that could conceivably be useful to any of these entities, I was very happy to note that only those key tools that have proven useful were addressed in the sessions.
The most interesting information I gathered about each is as follows:
-
Facebook
-
Twitter
-
LibraryThing
-
eHive
-
Issuu
-
Flickr
Hillary covered material on this, encouraging attendees to create Pages for their institutions, to "like" them, and to socialize their work at the institutions this way. I was particularly interested in the notion of creating pages just for one popular feature of your institution, like "Sue the T-Rex" at the Field Museum. It's worthwhile if your institution has an interesting collection or learning tool, to create a Page just for that. Users who may fear the commitment of "liking" your whole institution will probably have no problem liking the awesome coffee bar you have downstairs, or the Pirate Archives collection you have on display.
Also, it's good to remember to use your Facebook page. Post notes, create events and invite your fans to them. Don't pepper people will mundane messages, but don't just create the Page and expect the fans to come rolling in.
So, Twitter is something that many of us already know how to use, a lot. Ms. Mohaupt provided a good, comprehensive overview of the tool to the attendees, encouraging good practice for creating a quality Twitter account. One thing that I would additionally suggest is adding the SelectiveTweets app on your account on Facebook, so you can cross-post between Facebook and Twitter by just including #fb in your tweets.
Miss Mohaupt also talked about good social media strategy, and I found this to be the most valuable part of the first half of the morning's presentations. She stressed a few important facts. First, socialize the fact that you're going Social. Put the little Facebook button on your site, go ahead. Look at David and Goliath or WeLoveColors as examples of businesses that use a semi-intrusive approach to getting social media followers that is successful. How can you resist clicking on the dancing peas???
An aggressively friendly approach is also important, but don't be soulless and terrifying. Interact with your fans and followers; don't just act like a Marketing talking head. "Be real," were Hillary's exact words in this regard. "No one in the social online world wants to interact with a computer or machine; they're interested in the people behind [the social media profiles]."
I can't agree enough with this sentiment. According to Facebook statistics, the average user is connected to 80 pages, groups, and events at any given time. Many of these pages are stagnant or dormant. Others post too often and come off as incredibly annoying. For whatever reason, I became a fan of "Coffee" on Facebook a week ago, and after roughly 20 posts per day--no exaggeration--of inane things like "Don't you just love coffee!" and a slew of Starbucks mentions that certainly felt like spam, I couldn't undo my fan status fast enough. I'm still a fan of coffee in real life, though. They just don't know about it on Facebook.
Hillary mentioned some good approaches for real interaction on Facebook and Twitter. Have cool features like giveaways or online polls and petitions that are only available for your Facebook fans. Ask for suggestions for new programs or changes to existing initiatives. Asking questions in general is a great way to get people engaged. Hillary shared the example of Longwood Gardens' "Longwood Lens" weekly photo competition, in which a photo is taken somewhere on the property, and the first Facebook fan who guesses where the image was taken gets "mentioned" in the winning status update. So, you know, fame and fortune.
Kate Duffy spoke on four tools for social media in nonprofits, starting with LibraryThing. She stressed that it's free for the first 200 books, then after that, YOU MUST PAY. It's only $25 for a lifetime of books though, so it's completely manageable.
The most interesting things that she covered about this tool were the Legacy Libraries, a feature in which famous and notable book collections have been cataloged on the site, and users can search them. These include personal libraries of historic figures (example here of Thomas Jefferson's library), and can be used by LibraryThing users to construct online special collections. An interesting example provided was Providence Athenaeum's Legacy Library, a collection of the books in their original collection, which survived a fire in the library in 1758.
It's a tie between this and Issuu for my favorite tools of the day. eHive is a terrific, free online platform for publishing and classifying small museum collections online. This is good for low-budget situations, and can also be used for remote locations. The example given was that of the South Georgia Museum in Grytviken, South Georgia. The museum uses eHive to publish content, and so, despite their far-away location, they are able to share their materials with many virtual visitors in addition to those who come in-person. You can get started learning about eHive here.
There's also the eHive toolkit, which works well with Wordpress to allow users to create their own website for their museums while using the eHive features to publish content. One of their most famous examples of this is Rugby Moments.
eHive has a nice interface and classifies objects well, leaving plenty of room for defining appropriate taxonomies. It would be nice if the toolkit was more of an API, but it's a relatively new tool and is already allowing lots of interaction without constraints of a set interface, so that's cool.
Issuu is an online publishing platform targeted specifically at magazine and document publication. High-quality scans of documents can be uploaded to an Issuu account, in many formats. You can set up an account here.
Handouts from conferences, high-quality print ads, and updated newsletters can also be uploaded to this interface and then cross-published pretty much anywhere. The Museum Studies Department at UD even uses it to publish and archive their newsletter, Museum Studies in Motion.
Another great local example is the Museum of the Macabre, a Philly-based group of paranormal history experts and enthusiasts, who have exhibits, tours, even a museum gift shop, but no physical location as yet. Their ability to circulate material is thanks almost exclusively to Issuu. See the Museum of the Macabre's Issuu account here.
Users treat publications on Issuu like a print publication…they can read fullscreen, zoom in and out, subscribe to certain publications, and even get a slick little "page turning" effect when they go through the pages.
Sadly, Issuu attempted to launch an iPad app last year and for reasons undisclosed by Apple, they were rejected three times. Finally, they gave up. There is talk of an HTML5 optimized version that may go online eventually, but at the moment, there's no slick app to go with the awesome full browser interface.
This was probably the least useful tool, in my opinion. This isn't a criticism of the presentation at all; Flickr is basically a photo uploading tool. When it came about, it blew bogus nearly-free image hosting sites like Photobucket and Snapfish out of the water (yes I know they both still exist, but come on). It is still a tool that is integral to the Internet. I don't even want to think about the levels of near-apocalyptic panic that we would reach if Flickr suddenly announced they were going the way of the dinosaurs and Google Video. However, after seeing what targeted applications like eHive and Issuu can do for nonprofits and their image collections, Flickr seems almost like a backup. It's definitely a service worth using (I use it personally, and have a Pro account) but in terms of socializing content, I think this workshop covered some far more useful tools.
Overall, this was a very interesting experience. both the presentations and the ensuing group discussions. I went in not sure if we'd get anything but a crash course in how to fill out your LinkedIn profile and make friends on Facebook, but came away with some knowledge of new tools and unique uses of social media, a rare thing these days as people are inundated with bids for social media attention, as well as tips for how best to use it. This was one social media instructional experience that I got a lot out of. Thanks to Ms. Mohaupt and Ms. Duffy for organizing such a great event.
Thu, 14 Apr, 2011
So, mobile stylesheets are not the Holy Grail of mobile web development that they once were, but they do still come in handy. Rather than attempting to recognize the technology or the OS specifically, it's easier now to go by device width. I used this technology in order to have a "switch to mobile version" toggle in the footer of the full browser version of a site, but only on mobile devices:
<link rel="stylesheet" href="handheld.css" type="text/css" /> <meta name="viewport" content="width=device-width" type="text/css" /> <link rel="stylesheet" href="override-handheld.css" type="text/css" /> <link rel="stylesheet" media="all and (max-device-width: 480px)" href="handheld.css" type="text/css" /> <link rel="stylesheet" media="all and (min-device-width: 481px)" href="handheld.css" type="text/css" /> <link rel="stylesheet" media="all and (min-device-width: 1024px)" href="override-handheld.css" type="text/css" />
Let me expand this a little. In "handheld.css," we have the following:
#footer-switch{
display: block;
}
This allows the toggle switch in the footer of the full browser version to be displayed. In "override-handheld.css," we have, not surprisingly:
#footer-switch{
display: none;
}
This is, obviously, meant to hide the toggle. Please note, this CSS will actually remove the toggle entirely from the browser, not just visually, but for all hardware including screenreaders, as if it doesn't exist. This is our goal though, as we only want to call "override-handheld.css" when this particular navigational element should not exist.
So, in the first line, we call the "show" CSS. We do this as a "just in case," should all of our conditionals fail for an edge-case mobile user, the switch is available.
This little line -
<meta name="viewport" content="width=device-width" />
is used to help ID the device width, and is mostly needed to make Android 2.2 and beyond play nicely with mobile stylesheets. Without this, Android devices running 2.2 and above will simply ignore these media queries.
Now, these last three -
<link rel="stylesheet" media="all and (max-device-width: 480px)" href="handheld.css" type="text/css" /> <link rel="stylesheet" media="all and (min-device-width: 481px)" href="handheld.css" type="text/css" /> <link rel="stylesheet" media="all and (min-device-width: 1024px)" href="override-handheld.css" type="text/css" />
work for all other mobile devices. Most devices will be served by the first line, as many handhelds still have a width of 480px or less. The second line is for (again) many newer Androids, some Blackberries, and of course, tablet devices (*cough iPad cough*). The last line of CSS is only called for desktop devices, and this hides the mobile toggle switch. Win!
And speaking of iPads, if your mobile optimized site needs some love especially for the iPad or tablet devices, you can use this same technique in your mobile site's CSS. Just throw this into the header -
<link rel="stylesheet" media="all and (min-device-width: 481px)" href="tablet.css">
and put your tablet-optimized CSS into the appropriate file. Yay, many conditions!
Fri, 29 Oct, 2010
So there's this trend on Twitter on this #FollowFriday (apologies for the hash tag; it's just a force of habit) of people tweeting the Twitter usernames of all the people whom they follow on Twitter and would like to meet in real life. I took a look at my list and here's what I came up with:
People I follow and would like to meet:
- @clifftyll
- @dboudreau
- @jmspool
- @heyrocker
- @smashing
- @pixeldiva
- @Jennison -> We've met informally at a few Accessibility Camps and meetups
- @tbabinszki
- @NikLP ->I can't believe I still haven't met this guy in person
I follow over 150 people on Twitter. If that list seems small, it's not because I'm uninterested in anyone, but because I realized, as I was looking at my list, that I've actually met a fair number of the awesomely brilliant people I follow. Some of them, I'm even fortunate to know in real life. These include:
Wed, 7 Jul, 2010
My presentation materials for "Theming Views" and "Thich, Rich, and Accessible" (accessible rich media) presentations from DrupalCamp Chicago, June 2010, are available here:
- Theming Views: get it to "look right" - presented at DrupalCamp Chicago, June 2010
Slides | Abstract - Thick, Rich, and Accessible: incorporate dynamic content, scripting, and media accessibly - presented at DrupalCamp Chicago, June 2010
Slides | Abstract
See my Presentations and Posters section for the full listing of my presentations.
Wed, 12 May, 2010
So Lullabot has these awesome podcasts that they do with various awesome people in the world of Drupal development. When I was at DrupalCon San Francisco last month, I was interviewed about my accessibility presentation and my work at Drexel for one. Here it is:
Some other really cool podcast interviews from DCSF that I highly recommend:
- Everett Zufelt on Accessibility in Drupal
- Jenn Simmons on Usability, CSS3, and Getting Bartik into D7
- Dries Buytaert on the State of Drupal 2010
- And my personal favorite, Jack Aponte on Diversity, Power and Privilege in Open Source Communities
Enjoy!
Thu, 22 Apr, 2010
Wrapping up a great, productive DrupalCon San Francisco 2010! I've created a page with slides and video for my accessibility presentation here:
- Accessibility in Drupal 6 and Drupal 7 by Katherine Lynch
Libraries presentation slides/materials to come. <smiley>
Fri, 9 Apr, 2010
As a matter of curiousity, I took a look at my iTunes "Top 25 Most Played" playlist. I've had the same iTunes library for about a year, so the dataset is pretty comprehensive, with the most played song at 69 full rotations, and #25 coming in with 37 plays. However, the list is kind of...unbelievable. Bear in mind, I most often listen to iTunes when I'm coding.
By the way, I issue a challenge to anyone else out there to go into their music player, find their top 25 most played songs, and post their list on their own site/blog and/or Facebook, no matter how embarrassing. :) May you learn as much about yourself as I did about myself. :) Plus I just listened to My Hero for what is the 43rd time on this player.
Here's the spread:
(most-played at the top)
