Should kids have to blog in school?

I was discussing this with some friends the other day, and realized that I had a rather conflicted attitude toward this idea. On the one hand, it is quite reasonable to want to get kids in school to write, and while keeping a journal is not entirely out of fashion, the up-to-date way to do that is to write it in a blog. On the other hand, asking a 3rd grader to write to a blog that will be publicly viewable on the internet is a bit unnerving. After all, developing his or her own web presence and persona seems to be a bit ambitious, and it is unlikely that elementary school kids have the experience to temper what they write (it is clear that high-school students don't given the number of scandals (sorry too many references to be comprehensive)).

I don't know about you, but I know I think very carefully about the things I write for public consumption, whether they are the research reports that I do for my work, entries in this blog, comments on other people's blogs, statements about my current activities in facebook or twitter, and even in email. The knowledge that I have about what is appropriate to put in these kinds of communications comes from years of experience. I am troubled by the idea that we would ask an 8 year old to do the same things. On the other hand, we do ask our schools to teach our children modern, up-to-date skills. Presumably anyone reading this post would think that blogging was among those skills.

Of course, since the particular case would be a school assignment, presumably the teacher would provide some oversight. On the other hand, it seems like you are relying on the teacher to preserve your privacy in a way that is above and beyond what could normally be expected. After all, you would probably expect a teacher not to publish directly attributable statements made by your child on his or her own blog. But blanket rules are easy to follow. .

One obvious answer is to make the blog private. This way, the only readers are those within the allowed circle. Even this is unclear.. as we do not know all the parents in the class, and while our school system has an "appropriate use" contract for the internet that the students must agree to, the parents are certainly not bound by it. Even in this model, instead of just one teacher being accountable for privacy, we now have some 42 parents, plus whoever they (or the kids) give the password to.

It is also unclear to me whether or not this is "fair".   Clearly, this activity creates an unfair situation for those that do not have or cannot afford a computer at home, even though both the elementary schools and the public library in our community are well supplied with computers, so there are plenty of out-of-house possibilities for access.

I am also concerned about the publicity of it all. From being a parent, it is very clear that there are elements of a child's personality that seem to be present from a very young age. There are quite a lot of children who would be thrilled by the idea of something that they have done being publicly visible, but there are just as many that would be uncomfortable with this idea. Giving a journal to a teacher whom they trust is quite a bit different than making it available to all of their schoolmates, parents, or any random person.

So, do we ask our kids to blog in school? Or do we we still keep a journal in an old-fashioned notebook? At what age is it OK to blog?

Gartner Blog Network is up

Just to let you know, the Gartner Blog network is up, so you can find my posts about the technology world, and lots of stuff by my colleagues over there. I will try to dual post on here as well, but at the moment that is not working. My first post in the other blog is here.

Back in the blogosphere...

Well,
Now that Gartner has changed a policy that made it tough for analysts to blog, I should be able to get back to commenting with some regularity. I am spending most of my work time these days understanding how people are leveraging SOA, and digging into specific styles like the use of Web Oriented Architecture.

We have gathered a lot of really good data about SOA adoption, justification, value capture, technology, skills from a worldwide pool over the summer, and I am spending a lot of my time analyzing and writing that up.  The rest of the time is spent looking at how people are doing things, and in particular how they are following the WOA style. If anyone has any good examples they want to share, please let me know.

it's nice to be back

Bob, Dave and the curse of email

Modest thread started by Bob Sutor discussing sharing documents. Dave Berlind picks this up with an good description of all sorts of alternative approaches to emailing things around. Unfortunately, the fact of life at most organizations is that email remains the primary mechanism for information sharing. While Dave did not say this directly, a lot of web junkies assume that much of the new web-facing technology will supplant email as the mechanism for sharing. Being the contrarian that I am, and just looking at how I do things, I think that the opposite is likely to happen. Instead of Wikis and blogs replacing email, we will add wikiesque and bloglike capabilities to our email systems.

Today, I rarely detach things from email. I use the Yahoo version of the X1 search engine to search my local email, and (unfortunately) have a separate search engine for my corporate intranet. This is not perfect, but I find that the distinctions that we make between thing based on their technology often do not make sense. It is very common for someone to send me something with the assumption that all I want to do is read it, and I later edit it into something different to use in another context. My entire approach is centered on email as the principle repository of information that is relevant to me.

It is a bit of a chicken and egg problem to figure out why this is since email is the primary sharing mechanism reinforces the use of email for information organizations and sharing. However, I think the more fundamental reason for this is that email is organized the way I think. When I am looking for something, aside from the topic, or some key words that might have been used, the things I am most likely to remember are when I first saw it, and who it was from. Maybe this is just because I am so tied to email, but I recall a study that was done in the (paper-based) 1980s, on how people with incredibly messy desks still managed to find things almost as fast as the compulsively neat. The conclusion was that the mess was actually organized, primarily by time and sender, as opposed to the neat people who had some kind of taxonomy they used. The neat people were better at finding one-off, obscure things, but the messy people were just as good at finding those things that related most closely to their day to day jobs. (if anyone has a reference to the study I am thinking of.. it came out in about 1987, and I remember seeing it referenced by some folks who were proposing alternate models to the relational database... see? )

So in the end, I think what has to happen is that we need to add these web-like features to email, so we can link back to shared originals, so that I can update an attachment an have the update be reflected back in the original document etc... We have already progressed somewhat in making email searchable, although this can be improved as well. Clearly, there are some problems with email (being pushed information that I am unlikely to use) but this is more of a mechanical question (is the email I am looking at a single copy for me, or a shared copy for my distribution list? )

Maybe the socialization of blogs and Wikis will replace the email organizing mindset, but I think it is more likely that they will morph to become part of the email of the future, rather than supplanting it.

UI terminology gets ugly

Client/SOA - Wikipedia, the free encyclopedia

Oy, talk about buzzword proliferation..

Isn't this the same as a rich and thin client?

It has become quite amazing how confusing the discussion of client-side technology has become. IMHO, there are three issues that need to be discussed with regard to the client:

1. The technique used for managing session state
2. The page refresh model


3. Visualization mechanism

I am probably not dividing this up exactly right, but it seems to me that people tend to get these things all mixed up in their discussions of UIs. People assume, for example, that AJAX (which is really at its core a discussion of the page refresh model) is tightly bound to a whole host of pre-built widgets that exist in a framework (which is what most of hte AJAX frameworks provide). However, the AJAX-ness of the thing is not actually int the framework, but in the fact that framework elements and their data can be loaded on demand within the page. This Client/SOA word (ugh!) is really about managing session state on the client, which is hardly a new practice (That is why you have all those cookies, after all.. ). This type of interaction is necessary, but not sufficient for a REST-style architecture.

I hope that the market reaches some rapid consensus on terminology here.. this confuses me, and I get paid to pay attention to this sort of stuff.

Sorry this blog has been silent

Sorry this blog has been pretty silent. I am sure there are no readers left :)

However, I have a good excuse. We had a new family member arrive about a month ago, and having two is definitely more complicated than just 1+1.

Will get back to it eventually...

Dan

The relationship between SOA and Ajax

Several discussions about the relationship between SOA and Ajax are floating around now. (First one was this entry from Dion Hinchecliffe, with a dissenting opinion by Nick Malik, and some additional commentary by Dare Obasanjo.

This is actually the most interesting part of the entire discussion of the evolution of web services. It is very clear that there will be a large set of fairly fine-grained and specific services that will be made available due to the creation of AJAX style applications. It is also true that most of these services will not be terribly reusable. However, in parallel, there are a large number of initiatives that are attempting to create non-browser UI mechanisms (see Konfabulator. These mechanisms would be perfect candidates to consume the services that are designed for Ajax. (Yet another example of the changing nature of the contract between server and client, ) This kind of thing represents a specific set of services that will be implemented in a particular style, and will not use SOAP and WS-* stuff. There will be other sets, one of which are those connections that are most similar to traditional integrations, which will mostly use SOAP. There will be several other categories as well.

The point is that what distinguishes these services (and why they will probably use different mechanisms) is the expectation that is needed from the infrastructure. The AJAX style services need to be fast, and also need to be relatively easy to program. The Integration services need what they have always needed.. Message oriented middleware.. which is a collection of capabilities (security, reliability, state transfer, etc... ) which are most likely to be implemented with SOAP. I expect that many of the content related services will be ATOM, RSS or something very like both.

So on the one hand, the idea that AJAX will be a manifestation of services as many people define them is not true, they are a slightly different class of beast. However, they will be a very important class, and this phenomenon will have a tremendous impact on the concepts and use of services on the web.