Tag: Design

All Helvetica. All the Time!

Trying out a new design in which I Helveticize myself. Bold. Perhaps a little too bold. I haven’t decided yet.

I Need a Website: What Should I Do?

This is how I responded to a friend looking for website advice. My friend was at the very beginning stages of getting a website made and wanted to know how to begin. I think my advice is applicable to a lot of websites so I’d like to share it with you.

My friend needed a site to promote a musician and potentially sell music/merchandise. The following is my response, almost verbatim. Names have been changed where appropriate.

The First Thing You Should Do

The first thing I would do is write. Write the message(s) you want to tell people about Fred. The type of web site you are describing is part billboard, part brochure, and part catalog. You need to sell Fred before you can sell his music or tickets to his shows.

If it were me, I would approach it in this order:

Who is Fred’s audience? Who, demographically speaking, already likes his music? Additionally, are there any other markets I want to reach?
What are the different purposes of this web site? E.g., “sell Fred to Fox Entertainment,” “sell Fred to a specific band or theatre company,” “sell music and merchandise to his fans,” et cetera. Fewer purposes and a narrower focus are better.
Are the site’s purposes/audiences similar enough that I can accomplish everything with one web site? Do I need one for his fans and one for Fox Entertainment?
What other music/musicians/bands do the people I want to reach listen to? How do these musicians/bands market themselves? What do their web sites look like?
Does Fred’s audience buy stuff online? Are they the type of people who would actually buy an MP3 or a CD from Fred’s web site?
Among all the different musicians/bands that Fred’s audience listens to, where does Fred fit in? Where do I want to position Fred in the market? Is he edgier than X but softer than Y? He’s got the heart of Jimmy Durante and the soul of Stevie Wonder… et cetera.
Taking all of that into account, including all of the demographic and psychographic information available to you, write Fred’s message to the world. What does Fred bring to the world that no one else does? What is it about Fred’s voice, character, persona, stage presence, nuance, heart, his song choices, and any other abilities or qualities that people should get excited about? In short, why should people care?

I’ve Written That. Why Am I Writing This?

Okay, so I’ve written all of that. Why? Because web design is just another type of design. You can’t design without something to design around. You can’t write a song without knowing the subject, knowing your audience, and knowing everything you want to communicate to your audience.

(That’s not exactly true, of course. You can meander your way through writing music, jotting down any stream-of-consciousness lyrics that come to mind, but you’ve got to be really good to pull it off. Most people aren’t good, which is why popular music today sounds so shitty. There’s almost no consideration for craft. The same goes for most other creative endeavors.)

The other reason I’m writing first is because sometimes, in the middle of writing the message, I discover that the message is something entirely different than what I thought it would be when I started writing it. Like writing a book.

Web designers take your message and craft it into a digital experience that communicates directly to your specific audience. The best designers find a way to craft a site that feels like home to your audience, as if it was built especially for them, which translates into sales, positive reviews, and word of mouth advertising.

I consider the act of creating the content (in your case, the music) and the message about that content–and doing it first–to be absolutely essential to a successful web site design. If you start with design, you may get something nice but, at best, it will look and feel like every other web site you’ve ever seen about a musician or a band. It ends up looking like the endless rows of tomato sauce in the grocery store.

However, if you start by creating the best content and the best marketing message, you can design a site to fit. It’s a bespoke suit versus something off the rack from The Men’s Wearhouse. I’m not saying there’s anything wrong with The Men’s Wearhouse, but a bespoke suit communicates something about the wearer that The Men’s Wearhouse cannot.

Okay, I’m rambling.

I Believe You. What Do We Do Now?

What about getting it done? I think you have lots of options available to you. You can go from free to $10,000+ depending on your needs. If you just want something up now, I would visit any of the popular blogging sites like Wordpress.com, Typepad.com, or Blogger.com. You can be up and running within a day with something very simple with which you can communicate news to his audience. Many of these types of sites also have no fee, which means you can discard it when you outgrow it.

A step above that would be contacting one of Fred’s friends. Does he know anyone with techie skills who’d be willing to set up and/or design something and then keep the software up to date? Once again you can use free website/blogging software and just customize it for your needs. The only hard part is finding someone who knows how to set it all up and is willing to continue maintaining it.

A step above that is hiring a contractor who can either manage the project for you or do most of the work. Most individual contractors are good at one thing: either graphic design or web design¹, but usually not both. The ones who are great at both cost more, obviously.

A step above that is hiring a web design firm to do it all for you. This is the bespoke suit level. Costs vary but you can expect to pay anywhere between $50 and $150+ per hour. Sometimes firms will give you a bid on completing the whole job for a set price.

With a simple web site, a good firm can handle the design and creation of the site in about a week or two, depending on their work load. More complexity leads to more time. E-commerce sites (those that sell merchandise) are more complex and expensive than brochure/billboard sites.

If you’re going to go with a design firm, I would also recommend finding a copywriter, assuming the design firm does not have someone in-house. A copywriter specializes in crafting your message into gold. And since the message and the content are the most important things, it’s a service worth paying for at that level of web site. The copywriter will usually work with the design firm since the message should go hand in hand with the visual design.

Unless you have an interest in learning how web sites work and how they’re built, I would highly recommend handing over every part of the design, construction, and maintenance to someone who does. Whether that’s a friend, a contractor, or a firm depends on your needs and your budget.

Again, without any content it’s really hard to know what your needs are. It’s like trying to find the right book publisher before you’ve written your book. Write the book first, then publish it.

I hope that’s helpful.

Cheers, Harry

1. I’m lumping interface design, user experience, HTML, CSS, JavaScript, and programming into the generic label of web design rather than splitting them into their typical, jargon-filled job titles.

The Building of Jetrecord: Episode 2: Tell Me a Story

Sketches are quick, dirty, and cheap and that’s exactly how you want to start out. Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs. This step is all about experimentation. There are no wrong answers. — From Idea to Implementation — Getting Real

In the last episode I talked about high level goals for the project and I created a framework of rules for myself in order to help me make decisions. In this episode I’m going to follow one of the rules I created for myself:

11. Each feature must begin with a story discussing the feature and its impact, followed by sketches of APIs and GUIs, followed by test coverage, followed by implementation.

Cue film.

Download (right-click and save) QuickTime MOV (39 Mb) | QuickTime iPod MP4 (8 Mb) | QuickTime SMIL with captions (39 Mb) [Note: you must choose to open the SMIL file with QuickTime]

Am I Building the Right Thing?

One of the questions we ended with last time was, “How do I know that what I’m building is what people really want?” The answer is: ask them.

I’m going to follow a principle from Extreme Programming that says you should have a customer on site with you as you build. If you can’t get a real customer, one of you has to play the role of Customer. That means I’m going to play the customer for my own application.

Is this legal? Yes and no. Under ideal circumstances the customer should be someone who is not a developer because features are a business decision, not a programming decision. Really, it should be the client paying for the engagement or, in the case of retail software, someone from the business side of your organization who is familiar with the domain and the needs of your customers. By playing both roles there’s a possibility that competing demands will cloud the judgment either of the Developer role or the Customer role.

At the same time, I’m a customer of Jetrecord. At least, I plan to be. So in a sense I’m building software for myself, so perhaps the two conflicts cancel each other out.

In any case I don’t have a choice.

Why Agile (or something like it)?

In my limited experience as a developer I’ve come to discover that programming is simply a conversation you have with your code. Just like writing an article, it may begin on one topic and end up on something completely different. Thinking about programming this way fits my personality and the way I learn new things. I love things that grow and take on a life of their own. I also like to look at the big picture several times during the course of a project. If I keep my head down for too long it’s easy to get lost in the details and pretty soon I’ve veered off course.

Certainly every circumstance is different and you have to adjust for the needs of the project. Agile, Extreme Programming, and the like don’t work for everything. When the choice is up to me, though, and the type of engagement is a good fit, I like the communication, freedom, and feeling of progress Agile affords.

And, of course, let’s remember that I’m not following Agile methodologies to the letter. I’m using methods that will help me get the project done reasonably and responsibly. I believe this follows the spirit of Agile, if nothing else.

The Basic Features

The customer’s job is to define the features of the application. Here they are in broad terms:

Log flights
Visualize flights and hours
Export flights

I’m not going to worry about advanced and/or paying features yet. We’ll save those for later. If I don’t get these basic features right, there’s no point moving forward. These are the features that I, the Customer, believe bring the most value to the application at this point in the project.

Creating Stories

An Agile feature story is a “promise for conversation” according to Alistair Cockburn. That means, it’s important to get it down on paper so that we, the customer and developer, can talk about it at length later on. I’ll make sketches and write tests based on the stories I create. As for detail, I’m going to shoot for making each story completable in the span of one to two weeks, including tests.

Logbook Feature Stories

Users can log flights via a simple form
Users can log flights via a table/spreadsheet form, similar to paper logbooks
Users can log flights by importing CSV files from other logbook software
Users can log flights via authenticated API
Users can see tallies of their flights and hours, separated into categories of experience and aircraft
Users can export flights via RSS, JSON, XML, and a number of CSV formats based on the same logbook software supported by the import feature

Discussion

That’s enough to start. None of these have enough detail to tell me everything I need to know about the feature but they help me start conversations with the customer. They also tell me that there are some fundamental features that need to be developed in order support the ones listed. I would look at this list and begin discussing the following:

What fields are included in a flight? Are any of them required?
Please attach copies of example pages from a traditional paper logbook.
Which third-party logbook software should be supported? Please attach examples of the CSV output created by the software.

Also, we’ve talked about flights, but flights belong to users. That means we need a system in place for managing users and their needs.

What is required for someone to become a registered user?
How are users identified? By ID, by login, by real name, by nickname?
Do users manage themselves for things like registration, password changes and recoveries? How much intervention is required by admins?
Can users delete their own accounts? And what happens to everything they’ve created on the site when they do?
What about multi-user accounts? How are they managed? What happens to a user if the account they were associated with closes down?

User Feature Stories

Users can self-register and manage every aspect of their account, including paying for services and deleting the account, without intervention by an admin. Since email is the only method used to communicate with members, email is required to signup. Users must verify their email in order to begin using their accounts. Users are identified on the web site by their nickname. Users should receive email notification upon successful signup.
Users can login from the web site or from third party applications.
When users delete their accounts, all of their flights are deleted, followed by any aircraft used (assuming they’re the only pilot of the aircraft), followed by any routes used (assuming they’re the only pilot of that route), followed by their user account and any associated files. Users should receive email notification that their account has been deleted.
Accounts with more than one user have certain admin users who manage the account, including payment details. Admins can manage permissions for other members and invite and kick members.
When multi-user accounts are deleted by an admin, associated users will have the option to continue paying for features at the same level, upgrade to higher paying options, downgrade to lower paying or free options with features removed, or have their accounts deleted.

Discussion

It looks like we need a fairly complicated user management system in addition to being able to log flights. Ideally, with a larger team, we could work on both at the same time. However, since it’s only me, and since I’m also the customer, I’ve decided that the user management system is the first thing I’ll do after setting up my development and production environments.

Sketches

Again, these are sketches. Not blueprints or wireframes. Not schematics or Photoshop comps. They have just enough detail to let me know what I’m building so I can begin creating HTML mockups, acceptance tests, and unit tests. Ideally, as the developer, I’m drawing these while seated next to the customer so we can make changes quickly and throw things away if need be.

Flight Forms

User Forms

User API

Inventory

At this point I should be able to take the sketches and start building the application using whatever language I choose. I had a great time using the Ruby on Rails framework to build version 1 and I’ve decided to use it again for version 2. It’s well-suited to handle an application of this type and the Ruby language is, for lack of a better word, fun.

These are the things I need to get going (note: gems are installed with RubyGems):

Ruby
RubyGems
Ruby on Rails
PostgreSQL (you can also use MySQL if you wish)
ruby-pg gem (Ruby PostgreSQL interface)
- Note: I had to install with “gem install pg” instead of “gem install ruby-pg” to get the most recent version
- Find a gem for MySQL if you’re using that database
RSpec Rails gem
Cucumber gem
Capistrano gem
Git

Optional: Ruby on Rails comes with a simple web server that we can use for development purposes. However, I’m going to set up and practice using the server that I will use in production, even though the OS will be different:

I’m not going to cover installation. I assume you can follow the instructions given on their respective web sites and that you know how to use Google. Assuming you’re going to follow along as I write code, if you’ve never worked with Rails before I recommend installing everything and working through any of the simple tutorials you can find on the web before continuing on.

Also, please note, from here on out I’m not going to talk about the topic of programming per se. If you’ve never programmed before, the rest of the series might be interesting to watch but otherwise might go over your head. Let me say, though, that there are hundreds of web-based tutorials that can teach you how to program. There are even some that use Ruby.

Coming Up in the Next Episode

I’m going to set up my Rails project and my Git source code repository. Then I’m going to make sure I can do an initial release. Until next time, cheers and happy flying.

Material You May Find Useful Related to This Episode

Extreme Programming Installed by Ron Jeffries

Designing Interfaces by Jenifer Tidwell

Universal Principles of Design by William Lidwell

Moleskine Storyboard Notebook Pocket

The Building of Jetrecord by Harry Love is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License. When code, text, or media in this series is not created by me and is not in the public domain I will provide links to their sources from which you can find their respective licenses and terms of use.

The Building of Jetrecord: Episode 1: The Tabula Rasa of Doom

We were out at our family cabin in Bolinas, and he was at the kitchen table close to tears, surrounded by binder paper and pencils and unopened books on birds, immobilized by the hugeness of the task ahead. Then my father sat down beside him, put his arm around my brother’s shoulder, and said, “Bird by bird, buddy. Just take it bird by bird.” –Anne Lamott

I don’t think any of us ever realizes the hugeness of the task until we sit down with our materials and attempt to make sense of it all, even though the whole making-order-out-of-chaos thing is highly overrated in my opinion. Nevertheless, that’s what I’m going to do here in this series. I’m going to take a seemingly simple task–building an online logbook for pilots–expose the underbelly, cut it apart, and then put it all together into a fantastic, cohesive product that everyone will love, including me and you and every pilot you know.

Why? Because I believe we are created to do two things: experience pain and build things. Sometimes these are one and the same. I hate to admit right from the start that this is a task to which I feel compelled, by which I feel repulsed, and about which I feel nonplussed but apparently we’re in a new age of transparency so I’m starting with me, as Michael Jackson would say. I both love and hate computers and projects. And it always happens that about the time I’ve finished a web project I’ve forgotten all about this crummy beginning stage and am strangely excited to do it all over again.

Cue film.

Download (right-click and save) QuickTime MOV (49 Mb) | QuickTime iPod MP4 (7 Mb) | QuickTime SMIL with captions (49 Mb) [Note: you must choose to open the SMIL file with QuickTime]

It Begins Like This

I’m building version 2 of an online logbook for pilots called Jetrecord. This is my attempt to record and share the process.
This is not an exercise (please place your hands inside the yellow circles); it’s the process of building a genuine application that is already live on the web. What you see here is what will be released for version 2. I’m hoping that by sharing something real you’ll be inspired to create your own projects and you’ll see what it’s like for one developer to wade through this stuff.
As far as sharing goes you are free to take the code, the text of this series, and the videos and reuse, repurpose, and remix them under the terms of the Creative Commons Attribution-Share Alike 3.0 United States License. More details are at the end of this post.
My other hope is that we can learn from each other. I am not an expert, as will become more apparent as the series goes on. Please contribute your knowledge in the comments. Can something be improved? Do you have a suggestion or a critique? I want to hear it. Please keep it constructive, though. Shuriken are not allowed.
If you’d like to contact me by email concerning the series, use harry@harrylove.org.

The Scope of the Series

The process of creating a web application from start to finish involves several subjects and my plan is to explore breadth rather than depth. That is, I’m going to talk about whatever will help me complete the project and I’ll mostly concentrate on the places where subjects overlap. If I don’t explain things in enough detail, I apologize. The truth is I may not know enough about a subject to explore it in depth. I’ll try to point you to the places I’m getting my information. Don’t hesitate to speak up if you’d like me to say more about a particular topic. If I have something more to say, something worth creating a new episode for, I may just do it. Otherwise, of course, I’ll point you to my sources.

Let’s Start with Questions, Goals, and Rules

I’m going to start this project the same way I would approach an essay, article, or presentation, by asking questions and then stating goals and rules. You don’t have to do it this way. This is how I do it because it works for me. I’m going to say that just once. It applies to everything I’m going to do from here on out but I don’t want to bore you to death by repeating myself every episode (there’s an important programming principle in there somewhere).

Questions

What do I want to build?
- I want to build a web-based logbook for pilots.
Why do I want to build it?
- I love aviation, data, and the connections made when data cross paths.
- I am building this because it’s a product that I myself will use.
- I have surveyed the available logbook software, both desktop- and web-based, and have not seen any that use the same approach to building logbooks that I’m using to build Jetrecord.
- I believe this is a product that can work in concert with existing desktop- and web-based products.
Is this an art project or do I need to consider my audience?
- It’s both, but I am building this product for public consumption so I need to consider my audience.
Who are the primary people groups in my audience?
- Pilots
- Air and ground crew
- Affiliates
- Aviation buffs
- Their family and friends
Do these people need this software? Why should they care?
- Pilots must show proof to governing authorities that they have obtained any necessary knowledge and flying experience. Logbooks have been the standard method for recording flying experience for several decades.
- The second two groups may have business concerns with the logbooks but will otherwise not need a logbook of their own.
- The last group is important to consider because the entry of each flight will be made public, suitable for sharing with family and friends in the same way that family and friends share news, pictures, and video through blogs.
Can I afford to build it?
- The operating system, programming language, web framework, web server, and database server I am using are all available under open source licenses.
- I have a computer that is well suited for the purpose of building a web application using this software.
- I have some good software to edit the code and some to create and edit graphics for the web site.
- The web application is currently hosted at Joyent using the $125 per month Accelerator option and there is room to grow using the current resource limits; there are both horizontal and vertical scaling options available at Joyent should the application outgrow its resources.
- My company bank account is free but I may need to switch to a paying account if Jetrecord becomes very popular to the point of making more than a few hundred deposits per month.
- The merchant account and credit card processing fees per month have been quoted from a reputable business at less than $50 per month.
- The cost of doing business in Longmont, Colorado as a Sole Proprietor is a small annual fee.
- I have access to help in preparing my taxes.
Can I afford to maintain it and keep it running for years to come?
- If the current ongoing fees are any indication, the answer is yes. Obviously, in the best case scenario, if Jetrecord suddenly jumps from 1,000 users to 100,000 I will need to upgrade the servers a bit. I may also need additional partners or staff to help manage the workload.
Do I have enough domain knowledge to build it?
- I have enough knowledge about aviation and logbooks to make a good product.
- I have already built version 1 and it has been well received by the pilots who use it, including both general and commercial pilots.
Do I have access to information about the domain?
- I have access to the FAA’s regulations concerning logbooks through their web site and also via the FAR/AIM book.
- There are many web sites, magazines, and books that focus on issues concerning pilots and aviation.
Do I have access to customers and are they willing to teach me about the domain?
- I have access to the current users of the product.
- I am in contact with several pilots through Twitter and myTransponder.
- I have spoken with several pilots over the phone who have expressed interest in helping me.

Goals

Succinctly and broadly, what is the desired end state? For example, the goal of basketball is to have more points than your opponent at the end of the allotted time for the game.

The logbook is the key application, regardless of any related features.
It must be as easy as possible to get data into and out of the system both from within the Jetrecord web site and from the developer API.
It must be as useful as possible to as many classifications of pilots as possible, but focus on general and commercial aviation.

Mantra

Pilots Aren’t Robots Yet!

Rules

I’m writing some rules for myself that will serve as a guide for the decisions I make. They are written with this project in mind only.

Rules should help us make decisions; this is the only criteria for adding a rule.
Modify or discard any rules that are not helpful.
Use the best design principles we know how to use and spend time researching concepts we are unfamiliar with.
Make forward progress; no product is perfect.
Follow the spirit of Agile methods for software development; remember rule #2 above
Keep documentation in the source code except where sensitive information may compromise security or business secrets.
Documentation is for developers and is an interface into the system; design it well.
Everything should be added to the source control repository unless there is a good reason not to.
Code that can be extracted into a shared library (gem) or plugin should be.
Favor gems, plugins, other libraries, and framework code to writing our own unless there is a good reason not to.
Each feature must begin with a story discussing the feature and its impact, followed by sketches of APIs and GUIs, followed by test coverage, followed by implementation.
Metrics should be built into the project early and often.
Questions drive the need for answers which drive the need to record data, not the other way around.
Build for data access first and GUI display second.
Build for universal access.
Build for progressive enhancement.
Browsers must prove their worth to be included in our support; mainstream use is not proof in and of itself.
See also Matthew Moore’s Ruby on Rails Code Quality Checklist; remember rule #2 above

Coming Up in the Next Episode

Next I’m going to write a brief outline of the basic application. I’m also going to sketch the application on paper and make a list of parts I need to get started. I hope you’ll join me. You can subscribe to the RSS feed in order to be notified when the next episode is up. I have also created a table of contents page for this series. Until next time, cheers and happy flying.

Material You May Find Useful Related to This Episode

The Art of the Start by Guy Kawasaki

Bird by Bird by Anne Lamott

The Spirit of St. Louis by Charles Lindbergh

Building Scalable Web Sites by Cal Henderson

Getting Real by 37signals

List of software development philosophies on Wikipedia

Considering a Screencast Series

Screencasting! It’s the teaching medium that’s sweeping the nation!

I love screencasts. Certain ones, anyway. Done well they enrich understanding. Done wrong they’re a snore and a half. I’m in the middle of redesigning Jetrecord and the more I redesign the more I’m considering redoing it from the ground up (and doing some screencasts about the process).

Why? Well, I’m looking at all the shortcuts I’ve taken to get to where Jetrecord is today and frankly, it’s embarrassing. Don’t get me wrong. I LOVE Jetrecord and I think it’s both a great idea and a great product. I just think I can do better. I owe it to my customers to make it the best it can be.

I’m also one of those people who loves great foundations; well, I love the idea of great foundations. I love talking about foundations, dreaming about them, planning them, scheming. But when it comes time to build the application I get so focused on delivering a great experience and a great product that I glance right over the possibility that I may change my mind on a few foundational things, that people involved in the project come and go, that features come and go, et cetera. I know it’s impossible to plan for everything but I know there are some things I could do a whole lot better.

When I build an application I put a whole lot of time into building great user experiences (I try, anyway) and just enough time into making sure the application keeps chugging along. I tell myself, “it’s not a problem until it’s a problem,” which is a great way of looking at life for most matters. 80% of the time, we really don’t need to plan for all the contingencies we plan for. Of course, it’s that scary 20% that keeps us awake at night with a death grip on our Blackberries waiting for that 3am email from the error system. (Thanks, Internet!) An example of a 20% problem would be the current financial crisis in America. We were doing fine ignoring the underlying foundational problems for a while but now it looks like we picked the wrong year to stop sniffing glue. So when it’s a problem, it’s a real big, fat, hairy problem, with mutated teeth growing out of a tumor in your stomach.

Granted, most of us don’t encounter these problems. For small, local, mostly internal applications, applications in which we and maybe 20 other people are the only users, the 20% problems can usually be contained. It’s when we move into the realm of needing to support thousands of users in multiple countries on a 24/7 basis that we start encountering the mutant teeth kind of problems.

Jetrecord isn’t quite the super-multinational app yet but I believe it’s going there. It will, I tell you!!! Moreover, I’m at a place in its development where stopping and doing the right thing makes sense. I’m redesigning anyway and my plans already involve a better foundation. If I wait until it actually is supporting 20,000 users in 20 countries, I’ll have quite a job on my hands. I’ve racked up some code debt and it’s time to pay it off–and start saving a little.

But why do a screencast about it?

For one thing, I’ve been a code leech for most of my career. I’ve written a couple free things here and there and released them into the wild but nothing too substantial. Mostly I’ve read other people’s books and articles, attended other people’s conferences, and taken other people’s free code samples. And truly, all of these things have taught me a lot and I wouldn’t be where I am without the generosity of many, many people. But I think it’s time I did something substantial, extraordinary, and excellent for others.

Second, it’s going to force me to write the best code I can. I’m embarrassed during code reviews if there are glaring mistakes so I’m going to try hard to make sure it’s worthwhile code because it’s public. I already know I’m going to have to do a lot more research to find best practices and I’m sure I will make mistakes and I hope someone will be kind enough to suggest improvements. This will benefit me and you as coders and ultimately it will benefit the applications we build and the clients and the users we support. Win-win-win-win-win.

Lastly, I’ve been doing screencasts since 2001, since before they were called screencasts. In one of my previous jobs we were publishing “help videos” in Camtasia on our web site to show users how to use the site and some of the software products we supported. I consider myself knowledgeable enough to make a good video, or at least, to give it a go. Whether they’re actually good or not is up to you.

Having said all of that, I still haven’t fully settled this in my mind. I want to do it. I know it would be good. However, screencasts take a lot of time to do right. For every minute of production video there’s 30+ minutes of material and mistakes that don’t make it in, not to mention planning, outlines, scripts, research, creating or finding other media like music, artwork, and extra video. Then there’s editing, producing, and finding a place to host it. It’s not unlike being a T.A. in grad school. You’ve got this whole other full-time teaching job to do while you’re trying to complete your own studies. (At least, that was my experience.) It’s both fantastic and super-sucky at the same time. And you don’t get paid!

So, if the series is going to show up, it’s going to show up here on this web site, and probably very soon because I’m already building the foundation for the next Jetrecord (which is going to rock, by the way; if you’re a pilot, you should use it). If I wait too long, I definitely won’t do it.

Okay, thank you, and now for my next anti-climax…

« Previously Next Page »