I recently purchased omz:software‘s Pythonista, which is a Python programming environment for iOS. Thanks to Viticci’s excellent piece about how it changed his iOS workflow, I saw how well-designed and powerful the program is. I’ve dabbled with Python on and off throughout my career and I’m always wanting to improve. This puts Python in my pocket, and after using it for a few hours, I can say Pythonista is worth the $5 entry fee.
The first script I decided to write is something I’ve wanted to have available on all of the computers I use—it’s a script that essentially linkifies bible references to make accessing them more convenient. In this iOS implementation of it, the workflow is that you:
- Copy the bible reference to the clipboard.
- Launch a home screen shortcut.
- Get navigated to the verse/passage in your bible reader.
The first iteration of this has some severe limitations, but it does work. Here is the script:
The main limitations right now are that 1) it doesn’t work on ranges. You have to specify a single verse, or an entire chapter. And 2), you must use the full book name. An abbreviation, such as Gen for Genesis will not work. These limitations present some interesting challenges that will give me the opportunity to improve my Python chops. I’d like to be able to support the various ways that bible passages can be represented, and I’m sure there are many edge cases which I haven’t considered. There is a bible reference parser project on Github written in Coffeescript which is well-documented that I’ve referred to a couple times and will continue to do so.
The bible reader app I use right now is YouVersion, which does have an undocumented URL scheme. It also has it’s own limitations: I haven’t figured out how to pull up ranges, and it may not be possible yet. So until that happens, I also won’t have a complete working implementation.
Here’s another talk I found by Bob Gower, (also of Rally Software):
- Review the work (5 min)
- What was completed?
- What was worked on?
- What came in out of band?
- What didn’t the PM know about?
- Issues (15 min)
- Post-its: Great, Bad, Idea, Puzzling
- Group them and vote
- Talk (30 min)
- Talk about them in rank
- A / M / L / A (5 min)
I’m doing some brief research about how to run our second retrospective. Here’s Jean Tabaka of Rally Software giving a short talk about running them:
- Retrospectives are about the team and not so much about the project.
- Plusses and deltas: What things went well? (+) What are things that didn’t go well? (delta)
- Wind and anchors. Similar, viewing the iteration as a journey.
- ORID: Objective, reflective, interpretive, decisional.
- 3 H’s: Helped, hindered, hypothesis.
- Consider making an implementation backlog
- Appreciations and apologies: a time of reflection at the end.
This helped me today. I was editing some html that included some superscripts. I noticed that the line height was being screwed up, so I searched and found this solution.
I’ve started an online course on HCI offered through Coursera. It’s led by Scott Klemmer of Standford University. My initial experience of the site and the course has been good. You can speed up the playback rate of the lectures, which is a big plus. The total lecture time for this week was about 40 minutes, which is certainly manageable. Subtitles are provided, as well as a transcription of the lecture. There are quick quizzes in the middle of the lecture which help keep you honest in terms of paying attention.
I just finished watching the first week’s lectures, which provided an introduction to the topic of HCI: a history of the field, prototyping, and evaluating designs.
The Power of Prototyping
They’re meant to be incomplete. You can think of them as a question, in physical form. As such, you will build different kinds of prototypes to ask (and answer) different kinds of questions:
- What might this work like?
- What might this feel like?
- What is the experience of using this?
It’s a vehicle for communication.
One example he offered was a prototype for the original Palm Pilot.
The designer created a prototype that was simply a pocket-sized block of wood. When the situation arose, he would pull the board out of his pocket and pretend to input information into it. This process helped them answer the question, What size should it be?
The lecturer gave a whirlwind tour of a handful of techniques you can use to evaluate a design: usability studies, surveys, observation, to name a few. This is something I hope to learn from this course. Without any formal training, the only basis I have when evaluating designs is my intuition. While I’m sure this has some value, I know there are established metrics and principles which can be applied to better quantify the effectiveness of a design.
In this course, we actually have assignments. I’m glad they’ve provided the opportunity to implement something real that will be evaluated and graded. I’m just not sure if I’ll have the motivation to do them. This first one focuses on Needfinding (a new term to me). It involves choosing a design brief, which is something like a theme or problem you want to solve, and then physically going out to gather data by observing and interviewing three people outside of your field.
The design briefs all sound very interesting. They are areas that I generally think about. The first is Change, and it has to do with using technology to help people make changes in their life. Things like FitBit, BodyMedia, quantified-self, Lift, Nike+ come to mind. The second brief is Glance, which addresses information overload. How do we display information that is relevant to the user? (Think Prismatic, dashboards, widgets). The last area is Time. Design something that changes the way people interact with time. Two examples from the course itself are Qlocktwo and Sleep Cycle.
The assignment part is where it gets trickier—who am I going to survey? Off the top of my head, I’m thinking of the barista at Commonplace, the butcher at WholeFoods, and a pizza-maker. I’ll have to think more about this, and look at what would actually work.
Our team ran our first retrospective yesterday. Being the first time anyone on our team has done one, and the first time I have ever facilitated one, there were certainly some parts that could be ironed out. But overall, it went very well, and we left the meeting with an objective and action item, which was the goal all along.
I structured the format of our retrospective largely after the schedule from James Shore’s book. It prescribes:
- Norm Kerth’s Prime Directive
- Brainstorming (30 minutes)
- Mute Mapping (10 minutes)
- Retrospective objective (20 minutes)
As people trickled in, I distributed 3 different colors of post-it pads. These three colors corresponded to:
- Things that went well
- Things that went poorly
- Things that were puzzling
I asked people to brainstorm on their own and fill out their pads and put them on the whiteboard. We spent about 5 minutes doing this and probably generated about 40 ideas.
The Prime Directive
Before moving forward with any discussion, I read out the Prime Directive had everyone verbally agree to it. In all of the literature that I read about running retrospectives, this step came out as critically important, so it behooved me to do it. It states:
Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
I knew going into it that it would feel forced and cheesy, and I did get feedback afterwards from someone that they felt it was unnecessary. For our team, because of our personalities, it did feel unnecessary, which is a really good thing. All of us have a good attitude about giving and receiving criticism, and would not resort to blaming or attacking. But again, being my first time, I opted to follow the script when in doubt.
Reviewing the ideas
Once we got through the prime directive (which in reality only took 1 minute), we reviewed the ideas that were generated. At this point, I wasn’t sure how to go over them, whether to read them all, whether to have the authors read them, etc. Eventually, I settled on reading each of them myself out loud. If there was any further clarification needed, people would speak up. At times, this led to more discussion, but I led us back getting through all of the ideas first. There would be more time for that later.
Mute mapping and voting
After we got through all of the post-its on the board, we did an exercise together to organize them into categories. This exercise is called mute mapping, and it involves people physically grouping the cards collaboratively without speaking. After a few minutes of this, the cards were arranged into several groups. We quickly gave each of them a name and voted on which ones we wanted to work on. There were two obvious categories with lots of “Things that went poorly” and “Things that were puzzling” post-it notes: Planning and Scope.
Coming up with an objective
The last step of this process was to brainstorm ideas on how we could improve on the two areas that we decided to focus on. Because these areas have been consistent pain points, this part proceeded pretty naturally, since most people had already been thinking about these problems and potential solutions. During the last iteration in particular, what happened was that we underestimated the effort of a task, which resulted in us delaying the release and pushing a lot of work off to a future time. We discussed how to improve this, and ultimately came away with something specific we could work on for the upcoming iteration: we will make estimates and record actuals on every issue. More than that, I think another result was simply a commitment to focus on estimating on planning.
When I first proposed running a retrospective, I was given a timebox of 30 minutes. This seemed like too little time to get through this process, especially given this was brand new, and I expressed this to my boss. That constraint was relaxed, and in the end, we were able to comfortably wrap up within an hour.
The general feedback that I got about the meeting was that it was very helpful and productive. We came up with a lot of ideas, then honed in on two categories that we wanted to focus on for this coming iteration. I’m glad that things went well, because now we have a mechanism to contiuously get feedback and improve. I’m looking forward to building on this, trying new activities, discussing more topics, improving team morale.
At a recent developer meeting, my coworker Justin, relayed his experiences with Lean/Agile development. It seems like he has a very pragmatic approach to these processes, which I appreciate. There is a lot of baggage and hype around the term “agile.” He preferred to use the term “improvement” rather than ascribe to a certain methodology.
His first and biggest point was promoting the concept of having regular retrospectives. I’ve long heard about these, but my notion of them was more the idea of holding project post-mortems. But as he began to describe them as being at the frequency of every iteration, a light bulb went off in my head. The exercise of having a regular retrospective would have a profoundly positive affect on our performance as a team. The idea is so simple and seemingly obvious that I am embarrassed about not having researched and implemented it before—meet after every iteration, discuss how things went, and create a few actionable items to improve the next time.
I think everyone on my team is keen on things improving, and there are frequent discussions about how things can be better, particularly when we are experiencing pain. But often times, there is no tangible, actionable change. By starting to do retrospectives, we can enter a virtuous cycle of continuously addressing the pain points and making incremental changes that make everyone happier, fitter, and more productive! I believe everyone experiences pain points, challenges, and friction during the course of a project, and they probably have ideas of how to fix them. The retrospective is a forum for that feedback to come to light, become points of discussion, and ultimately resulting in improvements. What really struck me was that, even though we had feedback, we needed to close the loop. Without a deliberate and focused time like a retro, these complaints and ideas were just sputtering out and dying.
I immediately suggested to my team that we begin to hold retrospectives at the end of every iteration, and we’ve got our first one scheduled on Tuesday. I started to do some reading about how to run one, what the goals should be, etc. I found that James Shore‘s The Art Of Agile Development was now largely available online, including the chapter about retrospectives. His chapter prescribes a script to run through and describes different challenges you might face. I’ll try to draw from some of his suggestions as I prepare to lead our first one.
Apparently I set my
@applydea maglus too close to our MacBook and rendered it unbootable:( OTOH, I should know better. OTO, really?
— Ben Tsai (@bentsai) August 19, 2012
The other day, I was using my iPad, along with the Applydea Maglus, nearby my MacBook. I noticed that bringing the stylus, which has a embedded magnet as its premiere feature, close to my MacBook caused the screen turn off. I mused that there was probably a sensor on the base of the laptop so that it could detect when you close the lid. After a few times of touching it to the bottom-right area, the screen went blank and did not come back. A hard reset didn’t bring it back either, so I set it aside and didn’t worry about it.
After further investigation, I believe I corrupted my hard drive doing that, and now I’m in the process of slowly bringing files and applications back onto a freshly-paved MacBook. I suppose that’s the one consolation—I have a fresh install, which is running Mountain Lion better than before.
I’ve been running CrashPlan, so I am fairly confident I haven’t lost anything critical.
How to restore an iTunes library
As a non-designer, I need all the tips I can get. Ian Storm Taylor says to never use black, and it makes sense:
One of the most important color tricks I’ve ever learned was to avoid using the color black in my work. Mrs. Zamula, my childhood art teacher, first warned me about black when I was in middle school. And I heard the same again multiple times at RISD. It sounds weird at first, but it’s good advice.
Problem is, we see dark things and assume they are black things. When, in reality, it’s very hard to find something that is pure black. Roads aren’t black. Your office chair isn’t black. The sidebar in Sparrow isn’t black. Words on web pages aren’t black.
Tina Roth Eisenberg, founder of swiss miss, spoke recently at TYPO San Francisco 2012 about the power of side projects. Her recent venture, Tattly, started as a side project and hit it big. She also created TeuxDeux.
Another story that came across my feed today was about how Flowdock also started as a side project and has apparently turned a little software consultancy into a product company. From an interview with the founder, Otto Hilska, three take-ways:
- Start small: Flowdock started as a side project. Sometimes, if you have serious resources, you can afford to dive wholesale into an idea, but for most people it’s way smarter to experiment and build within your means.
- Fix your own problem: Flowdock was their own customer. They typified the type of client they were trying to attract. This vastly simplifies the feedback loop required to create a good product.
- Play Nice with Others: Flowdock’s biggest source of customers is their integration partners. If you build your product so it syncs/has an API/connects with other apps your customer uses, you are building marketing channels directly into your product.