and coming up next...

Well, I saw an interesting news article last night. It was on a new format for a band of online stores. It was three (I think) stores that joined forces to create an online virtual mall. The patron walks into the store and wanders around to shop. Whatever you look at is described, but when you look at it, you can see the actual packaging. When you check out, you go to more "normal" web pages.

One of the participants is Amazon, so I'd expect the thing to go. There was another store that I'd heard of, but I didn't quite know what they sold. (It just seemed like a store when they were wandering through on the news article.)

I mention all this because this could be the shape of things to come for libraries. It would take a while, but the first library of Runescape might be coming. The good news is that there would be the option of putting librarians in that sort of setting. It would feel odd, but you could do it.

That was the one thing that wasn't mentioned in the new article, incidentally. There were no virtual salesmen trying to get (I assume) real, actual commissions. Neither were there other guests in the store. That also will probably need to change.

My guess is that there is a huge number of people who would love to see everyone in the store with them. There would be another huge number of people who would love to be able to browse the store with just their friends. Then there would be people who would want to browse the store with no one around. Then there are the people (of course) who wouldn't want a virtual store at all.

Anyway, I saw the article and decided that in a few years libraries will be trying to figure out how to do that, too. I guess we'll see.

Mention of a blog

Oh, there is another thing.

Kevin commented on a blog posting that someone showed him this morning during his sermon. I figure that was a milestone of sorts. I don't remember that happening often, if ever.

I suppose that means something about the changing nature of communication in this day and age, but I'm not sure what it might mean.

A Really Cool Panacea

Sometimes things work exactly right without any particular reason that they should. When this happens, I try not to complain, but instead to be happy with it and go on to the next thing. However, on the other hand, counting on this happening is a tricky thing. Computers, and technology in general, have a capricious nature, and it seems they pleasure in making things go wrong. In fact, most of my job as a computer guy was fixing or preventing problems. When things went well, I mostly spent time preventing problems -- when they went well.

Anyway, back to the matter at hand.

There are two opinions about technology which can occasionally cause difficulty with planning. Both answer the question "And why should we do this?" The two answers are

• "Because it's really cool." This occasionally combined with the comment that everyone is doing it. As a reason this is weak. It is also not helpful from a computer person's perspective. Occasionally the "coolness" is from an exceptionally well done thing, but generally not. Lots of Internet technologies (each in turn, I think) have had their day in the sun being the next cool thing. This doesn't mean that you avoid the cool stuff. What it means is that you need to be careful to do what is useful and reasonable, and it needs to be something that you'll enjoy and keep up with.
• "Because it will solve all of our ___ problems." New technologies do occasionally solve problems. Generally that is how new technologies come about. However, generally the problems they solve are the ones they were designed to solve. I'm leary of cure-all solutions, especially ones that require no work. I'm also not one that believes in deus ex machina. I've looked inside a computer. I know better.

So anyway, my opinion is generally the minority opinion in these matters, but I'm in favor of planning. Design a system to do something intentional, and preferably something important. If you do it well, it will solve the problem that you set out to solve. If you do the job particularly well, it might even be cool. If not, oh well.

With a web site of any size, shape or description the key is to have something to say. Start there. If you don't have anything to say, write, inform, tell, preach or otherwise communicate, a web site isn't the solution that you're looking for. In that you're looking for a message or a purpose. That is an entirely different process. (It is a process which I would liken to pulling one's heart out and setting it on the table before you that you might watch it work. But that's a different story.)

A ridiculous thing

I'm facing a technology problem of sorts this morning.

I'm trying to find something round to use in a demonstration for class. Sounds simple, doesn't it? Apparently, this is also covered by some sort of technology effect.

For starters I don't have any of the playground balls around the house, or a basketball for that matter. (Yes, I grew up in Indiana. I never really caught the basketball bug.)

However, I discovered that the jars and cans in my cabinet were not uniformly round. They rolled funny. A container of caulk that I found was a nice tube (with the pointy tip) but the caulk itself was not uniform inside the container. I know this because it rolled like it was drunk.

So, I think I needed to decide on a roll of blue painter's masking tape. What a silly thing. Today might not be the day to work on a server.

Either way, I hope the lesson works. Today is "Newton's first law" and "Newton's second law." Good stuff, really.

Change Management

Change is sometimes a hard thing. Professionally, I've tended to be an agent of change. Many people say this, perhaps. I don't know to what extent this is true for others, but I know that I have brought change into some people's work places.

Part of the difficulty is to realize that when you are introducing something new, something profound, change needs to occur. It's the needing that is the hard part. Something needs to go. This sounds like it is an OK thing. However, I have come to understand that part of my role as a computer person is to occasionally rewrite people's job description. If I understand that going into a project and if the other folks understand that going into it, then everyone is happier.

In fact, there are times that I have had conversations about how the job will be different before bringing the computer changes about. That may sound like the cart before the horse, but it isn't. In fact, it is generally the right order.

When the conversation is centered around questions like:

• What are you doing now?
• How do you do what you do?
• What does this office do well (that we need to continue to do well)?
• Can I see a sample of what you do and how you do it?
• What is the weirdest thing in the computer that you can think of?
• If you had two extra hours in the week, what would you do first?
• If you could cut two hours of work out of your week, what would eliminate? Why?
• What is the most tedious job you do?
• What is the hardest thing you do? Why?
• Where would you like to see your job improve?
• What paper runs through this office?
• Why are these papers important?
• What is the most important part of the week for you?
• What is the most important part of the year for your department?

These don't sound computer-ish, but I tended to want to understand the people that I was helping. Since I was a computer guy at a school, this meant that I was frequently working with (and for) secretaries. Secretaries are fairly important at schools, probably more important than the electricity. Of the three hundred desk tops at that particular school, seven of the most important dozen desktops were secretaries. The other five were running the cash registers in the lunch room (riot control is a big thing).

However, back to change management. Occasionally changing a process took years. Printing transcripts and printing report cards took years and years.

The first step was discovering that (once upon a time) the middle school secretaries hand wrote all the grades onto all of the the (hundreds) of student transcripts. When I discovered this I asked about how we could do the same process with a computer. Printing the transcripts (which is what the software wanted to do) wasn't really seen as a good option. However, I was able to print labels that would have the needed information. One label for the biographical data, and one for the year's worth of grades. This took a long time (for me). I also had to start it early in the year (relatively). It needed to be ready for the end of the year well before the end of the year. However, once that got going, it saved two people an entire week of work. That was a welcome change.

Moving from that to printed transcripts for the high school was levels more complicated. However, once it worked, I was pretty happy that it did.

The thing of it was that the printed transcripts could have been printed several years before the high school chose to do so. It didn't choose wrongly, it just took a while.

I suppose talking about change brings up the notion of progress. Change isn't always progress. However, if you set out to make progress steadily and not give up and ground, change happens.

-----

And, on that note here is a quip from Narnia (Voyage of the Dawn Treader) when King Caspian forbids the Governor of the Lone Lands to continue the slave trade:

"But that would be putting the clock back," gasped the Governor. "Have you no idea of progress, of development?"

"I have seen them both in an egg," said Caspian. "We call it Going bad in Narnia. This trade must stop." (47-48)

Project Management and Change Management

I've been trying to get caught up and ahead on the reading. I read a few of the articles on change management and project management.

The PMBOK articles seemed a little over the top really. Most projects I've worked on have been one man teams. I've worked computer jobs, and have worked on computer programming projects. As such, the project life cycle is something that I've encountered before. What I've run into in the work world is both fancier and less fancy than what is normally in the book.

For starters, part of this depends upon the sales department.

You see, if the sales folks are drumming up projects, you get requirements from the sales department folks. Hopefully, they haven't attached dollars and resource committments to the requirements before asking someone technical if the thing was possible short of half a billion dollars. Don't get me wrong, the sales folks generally are the ones bringing money into the company (which is a good thing), but if they promise something undeliverable you'll have unhappy clients (which is a bad thing). Generally good sales folks strike a reasonable balance on this one.

The next step is to work out enough detail that once agreed to neither side will feel cheated. That isn't how its stated in the book, I suppose. But that is the idea. The project folks need to know how big the project will be, and what their committments are. The client folks need to know how much it will cost and whether it will do what it needs to.

Assuming that the project goes forward, the next step is to figure out what will happen. Generally, this entails someone understanding the project, working out a schedule, breaking the project out into pieces (if it big enough to worry with this) and so forth. Generally, it is a good idea to talk to the client and confirm all the known facts of the project. This is particularly true if time has lapsed since things were written down the first time.

When I was programmer, I generally tried to read through the requirements (they were generally two paragraphs on a one page fax). I then tried to read through the project notes created by the person who wrote the requirements document. This was normally a technical person. I then tried to track down all of the documentation and data files associated with the project. Then I worked through it. I would then perhaps take a tiny step toward solving the project, enough that I could see what the hard, tricky bits would be. I looked for all the areas that I would need client opinions or approval. This might be how to use a client code, what do to do with weird data (names that are two long or have some weird character or phone numbers that are obviously fake or prices that are negative... weird).

Then I called the client. This was a change from when I first started at the firm. Generally I called right when I got the project. This was, in fact, the recommended method. However, as some of the projects had been in the queue for weeks, I decided that a couple of hours wouldn't make that much difference. In fact, it did. It meant that I didn't make the "other" phone call -- the one that normally came one day later with all the questions about the project. Since I normally had to call and leave a message with the client both times, this meant that it could take days to get running.

Having done all that, the next thing was to program the project. Generally, the projects were sort of all of the same type, just different flavors. For me, I tried to get enough info to finish the project without needing to call the client. The reason for this is that client contacts were much slower than normal work. When I called a client, I would either get the client and continue working or I wouldn't get the client. When that happened I would ask the client to call me back. If there was nothing else I could do on that project, it would move to the bottom of the stack. (The projects had file folders. I actually moved it to the bottom of the stack. My stacky tray held projects on hold, my desk held the project that was current.)

This actually meant that "good" clients got better service. Good clients were responsive, and good clients had opinions. Also, good clients cared about doing their jobs well. That may sound silly, but not all of our clients were good clients.

Oh, and good clients don't yell at programmers when they have a bad day. This is very important.

The next step was to show everything to someone else and have them see if it was correct. This involved highliting each character (including spaces) that we changed in any document or program. This also entailed having sample data and instructions (which have been used somewhere) which were also checked. Assuming that everything checked out, then it was time to deliver the project.

The next step was to inform the client that the project was ready for delivery. Generally I tried to log onto their system and get to the point where I could deliver the button with one more keystroke. Then I called the client. Assuming that they said that delivery was ok (it was possible that there was something else to consider), I would then deliver the project. The next thing to ask was when they would next be ready to use it. Occasionally, this would be immediately. If so, I'd check what I had done and walk the client through.

Then you wait. I had to support my stuff for a period of one month (or longer, depending) -- no questions asked. Obviously, part of the goal here was to not get calls about bad software. A bug that a client finds in one month is probably big, glaring and obvious. Leaving a big bug in a project is bad. Spelling the company's name wrong would fall into this catagory. After a month, the questions were from other people in my company (generally high up people), so small bugs were also bad. Also, you don't get paid to fix bugs. Really. We got paid hourly (as a company) to write the software. We got paid to fix the bugs early, we didn't get paid to fix the bugs we found late. The little bugs were the nasty ones. Oh, and generally the little ones have been around long enough to mess up everything else, which then needs fixing. Really, this is something to be avoided.

So, that is some of my experience with the project life cycle.

Later I may talk about "change." I decided this was getting crazy long.

Thoughts on Technology

If this blog is meant to be about technology, it would seem that perhaps a comment on the VIC itself might be in order. This is my first VIC class, and I'm not sure exactly what my thoughts are yet.

It did take a while to get things going. When the Indy group arrived at the last class period, there was some other class going on through the machinery. The class was about emergency plans or firefighting or some such.

The one surprise I had was the projector. Using paper copies with a document camera and a video camera pointed at the screen wasn't what I was expecting somehow. It seems that a paper backup is a good policy, even in a video conference. That was a wrinkle that I hadn't considered.

As for the rest of the VIC experience, I didn't get the full effect since I'm at Indy. I'd be interested to know what the "full effect" is like.

One of the little weird things about the VIC: I didn't know exactly whether the Indy class would be the instructor site for the class. At first, I did think that. However, when I saw that the contact cell phone number was a Chicago one, I wasn't so sure.

I'm intested in the technology, and how it plays out. There was an entire class of high schoolers using distance learning to take some college classes, and I was there when it was set up. In a way I'm wondering what I did (or helped do) to them.

RSS readings

I've been subbing at FCHS, and I did some of the readings while I could. This means that I'm doing the readings slightly out of order, and as time permits (during lunch and prep periods).

I've read the RSS section, and there are some things about it that were interesting.

I've seen the "feed" button on blogs before, and this includes on sites I've managed. Strangely, I've not really used the feed before. I had clicked on the feed, and I've taken a look at the XML, but I've not really used it. Partly, this is because I don't follow any blogs on a regular basis.

The sites that I've used before were corporate sites. In one case the organization was actually a not-for-profit that was international in nature. It would have been a good candidate for using blogs on an on-going basis, but it didn't (and still doesn't). The tool that was used to create the web site is one called Drupal. The Drupal tool allows for blogs and other interesting things.

The Drupal tool allows for most any number of people to cooperatively add and edit a site, and it allows for each user to maintain a blog. Each blog and several other sections of the site have an automatic feed that the tool provides.

As for the blogroll, I suppose there are some sites that I looked at occasionally, but I never really was concerned about whether I might miss a posting. There was one site that I looked at occasionally, and it was even mentioned in the book: "A List Apart." I browsed the site during lunch or after work on days that I had a meeting. In those cases, I wasn't necessarily concerned with what was "new." And in some cases I intentionally looked for articles on a particular topic. It just depended.

I'll need to think about the blogroll for future reference.

This is my first post on blogger. I've worked with other web sites, but generally they've been business sites.

This looks like it will be an interesting change. The key on this site will be content, or so it appears. Generally my contribution to a web site has been more heavily tilted toward the technical side. It will be interesting to see how well this site works from a user and administration point of view. So far it looks like the user side will be pretty good. The administration side might be a bit limited, but I might not be seeing it all.

As for the blogging, it will be interesting to see how that goes. In both of my classes last semeseter I had to participate in online discussions. I found that strangely compelling. One of the classes also had a journal component. I kept the journal on my computer in a web form. The tool I used was a different one, and again it will be interesting to compare the two.

The book seemed to have an unusual format in that it contained several (a surprising large number) of printed out web pages. I would have cut the number down to about one third of what is there. I would have cut the personal interviews down also. Having set up sites, the book seemed to be at a pretty simple level. I was hoping for something more -- something that would tell how to set up a blog site for an entire system (for example). This is at least a start.

The other thing that will be interesting about this class is the VIC (video classroom) piece. This is something that I've heard about from other students and even from other teachers. It seemed that for them it played out differently than a normal classroom. Having worked at a school that installed such a system (it was a high school), I'm interested in seeing how it feels. Hopefully it works well.