I’m speaking at OSCON this year about the Railsbridge Open Workshops. If you’re there, look me up. Otherwise, here’s a live stream:
We spent some time tonight arranging the Queen’s Round from memory:
Slides from my WebVisions 2010 talk are posted on Slideshare:
I will try to update this sadly neglected blog with a summary of said talk sometime soon.
When you boil it down, a lot of what I do for a living is search for information; competitors, new technologies, processes, shoes… well maybe not shoes. And I’ve gotten pretty good at it, enough so that I’m often asked to google things for other people. Here’s my best take on what I’m doing to get useful results:
If you can do these three things, you can get useful results for most searches on common topics:
1. Read really fast. I don’t know if this is the same as speed reading or not, but the ability to skim rapidly for keywords is critical to being able to sort out what you’re looking for from the masses of link spam. If you don’t know how to speed read, check out lifehacker.com or similar for tips.
2. Start with the phrases you would expect someone to use. Whatever question you have, chances are someone else has already asked it on a bulletin board somewhere Actually type in a whole phrase instead of just a couple of keywords – often this is all you need to do. For example “how to create a site map” will get you much better results than “site map”
3. It’s a big internet, be specific. Start specific and then broaden your terms if you don’t get the results you’re looking for. For example if you’re looking for the best way to generate a site map for a large site “best approach to site map creation for a large site” is the place to start. If the first 5 results don’t contain anything useful, then try “best approach to site map creation.”
Just following the tips above should get you something within the first page of results. If that doesn’t work, move on to the next section.
When that doesn’t work
Sometimes I’m googling for stuff that’s a little more obscure or non-technical (my hobby is costuming, especially historical costuming).
4. Don’t stop at the first page of results If there are sponsored results at the top of the page, that often correlates to the first page is full of search engine optimized pages. Most of what I’m looking for is *not* from folks that spend a lot of time on SEO. Before giving up on a particular search, I usually scan all the results on the first and second page and then click to a page further into the results (10th or thereabouts). If there’s nothing close to what I’m looking for then it’s time to move on to the next step.
5. Find synonyms. Maybe you’re searching for the wrong words. Click on the most likely results you can find in the first couple of pages. Focus on things that look like bulletin boards or discussion forums. Sponsored results also come in handy here; people who are selling you something will be trying to use clear language. Skim those pages looking for synonyms. Now repeat steps 1-3 using your new search terms.
If all else fails
6. Try a different type of search. If you can’t get what you want from a standard google search, take the same thing to image search. People’s captions and diagrams are often quite relevant. Click through the likeliest looking images and scan the resulting pages… If that doesn’t work, try an abbreviated form of your search on twitter. Then repeat step 5. Until it works
Note: This was supposed to be an easy post – take something I’m good at, break it into steps, voila. But when I started dissecting what I do it’s actually more complex than it feels… posting it anyway in case it’s helpful to others.
Lightboxes have come to replace pop-up windows as a way of drawing the user’s attention to particular information by dimming the rest of the screen. They are a great way of focusing user attention on a particular message or interaction. But, like pop-ups before them, lightboxes are a tool that’s easy to misuse. Here’s some simple guidelines for friendlier, more effective lightboxes:
Lightboxes are not a replacement for pages:
- Use lightboxes sparingly. A lightbox stops a user in her tracks. Are you sure that’s what you want to do?
- The lightbox should not cover more than 50% of the screen–if it’s that big, it’s time to launch a new page.
- Beware of scrolling in lightboxes — if there’s enough content in the lightbox to require scrolling, it might be time for a new page.
Dimmed content may be needed so keep it legible:
- Be careful how much you dim. If the overlay is too opaque, the user loses context, if it is too transparent, there is too much visual “noise” for the lightbox to be effective. 40% opacity seems to work well for a solid black overlay.
- If the lightbox depends upon the user being able to read the dimmed content, make sure the lightbox is repositionable and has clear affordances for repositioning such as a title bar with cursor change on mouseover.
Always give the user an out:
- When the user needs to take a specific action such as submitting a form, make sure the button or link is immediately visible and recognizable. Don’t depend on users to read your helpful instructions.
- When there is no specific action required, for example when expanding a thumbnail image, add a close control indicated either by an “X” in the upper right corner or with the text “CLOSE”.
I will post a serious entry about search techniques any day now. Meanwhile, somebody with decal or sticker making capabilities should make this a reality:
Idea courtesy of Fi’s decision *not* to be a ninja for halloween after all.
Primary Actor: User – A kitchen user. See related persona: “Mom – A thirty-something baker of pies.”
- User has access to ingredients consisting of:
- 9″ pie shell/crust (trader joe’s makes a good one)
- about a dozen apples (you can use Granny Smith if you can’t get Gravenstein, but then you need more sugar)
- 1 large lemon
- 1 stick of butter
- User has access to typically equipped United States kitchen including oven, cookie sheet, spatula, aluminum foil, pastry cutter and medium mixing bowl
- Oven is preheated to 400°
This weekend, I coordinated volunteers for the August Ruby on Rails Outreach Workshop for Women from RailsBridge. Over 50 people attended as students, and we had almost half as many volunteers as attendees. Sarah Allen has a great post on the workshop overall, and everything that went into it. I’d like to address what was, for me, the most intriguing aspect of the weekend — the way the teachers and volunteers self-organized to create a more effective workshop. The concept of self-organizing/self-directed teams is not a new one, it dates back to at least the 1940′s. But the wide acceptance of agile development methodologies have brought this approach to the forefront over the past few years. Although their benefits are touted frequently, in practice, they can be challenging to create and sustain; this weekend’s workshop offered some interesting insights on how to create an environment that encourages self-organization.
Theoretically, self-organizing teams evolve over time from hierarchical teams… but in this case 24 people, who knew each other only slightly, came together and taught 50 other people complex technical skills over the course of 10 hours. This happened with relatively little advance planning for the bulk of the participants. Despite, or perhaps because of (more on this later), the typical chaos of last-minute additions and cancellations, the weekend went more smoothly than many heavily-organized corporate trainings.
Here’s some of why I think it worked:
- Start informally. Installation had been previously identified as a roadblock to learning, so the first night of these workshops is an installfest where volunteers are available to troubleshoot as attendees go through the process of setting up a development environment. This had the added advantage of letting people get to know each other in a fluid, non-hierarchical manner so that they were better able to work together during the instruction portion of the workshop the following day.
- Establish clear goals and leave the details to the people doing the work. Excellent leadership counts for a lot; the Sarahs set (and repeated as often as necessary) a clear goal — everyone should leave the workshop having successfully deployed a web application. They provided the tools necessary to achieve that, but did not dictate how those tools should be used. Teachers were given a framework curriculum for instruction, but not a step by step training manual. The same materials were used by all the instructors but the details of how they were used varied per group and per experience level.
- Just-in-time roles. By nature, attendance of both volunteers and participants is unpredictable. This forces class assignments to happen at the last possible moment. While this was somewhat stressful at the time, ultimately it made for a better experience. Total novices got a more structured, lecture-oriented morning session that suited the larger group size, people with minimal programming experience were broken into 8 person teams and the remaining participants were divided into 3-4 person groups; a structure that worked very well for the different levels of experience. Because we were unable to create groups in advance, the groups that were created were the right ones for the situation… and because they understood the fluid nature of group assignments, our volunteer instructors did a fantastic job of assigning themselves to groups as needed and coordinating the training amongst themselves, with 3 groups merging and separating as needed. This is not something that would have worked nearly as well had we tried to assign everything in advance.
- Resource abundance. Thanks to the overwhelming response from the SFRuby Meetup group, the student to volunteer ratio was 2:1 — in addition to providing attendees with a lot of personal attention, this meant that volunteers could shift roles fluidly from searching for extension cords (lesson learned for next time) to helping with the door to helping teach. I think this is the hardest lesson to translate to the corporate environment. It is critical that there be enough people for priorities to shift without impacting outcomes. I contrast this with the last so-called “tiger team” I worked on, where due to pressure to be “lean” there was only one developer until very late in the project–at the retrospective, we identified that the team was not efficient until the development team was expanded so that the developer could do more than code. Many hands make light work… they also make better work.
There’s much more that went into the planning and execution of the workshop than I have detailed here, but what binds it all together is trust. Trust is a bountiful commodity in this all-volunteer environment, and perhaps that, most of all, is what allowed the rapid evolution of a large, self-organized team… but that’s a post for another day.
This is my 3rd attempt to start a blog. Sarah Allen of Ultrasaurus was kind enough to give me a kick in the pants after this weekend’s RoR workshop.
It’s taken three tries because I suffer from the knowledge that, in this day and age, anything I might choose to say has already been said, and you, gentle reader, can google it. Nevertheless, I will proceed, daunted but unbowed. Here’s what I want to write about this week:
- The RoR Outreach Workshop for women, where I met the aforementioned Sarah (and the other Sarah)
- The transition our team made from Scrum to Kanban over the past 2 months
- How I search… because I do it better than you. (Well, maybe not *you* if you found this blog. But better than most people.)
- My apple pie recipe.
That seems doable. We shall see, tomorrow.