so, it's been two weeks and i'm still thinking about the abstract on open systems design. the emphasis is on 'producing content'. period. it was almost like i wanted to exclude any kind of higher level manipulation. the goal was not to design amazing interfaces and intuitive systems - the goal was to simply produce content, and this idea, would in turn change the way we think about designing systems. the goal is not to present anything. the goal is to enable presentation. encourage it, even. now, this idea, could be very easily applied to journalism. all we really need to do is design the system to index the feeds. then journalists everywhere can begin to use the machine. they...
I find that Tom Coates' definition of Social Software is missing one of the more important aspects of Social Software. It really isn't about software. It that has more to do with people than it does with code. This is much like Social Engineering, which has more to do with people than it does with engineering. 'Social Software' illustrates how programming is beginning to change. We are now entering a stage where non-programmers are able to build 'software', and this 'software' is beginning to have serious implications on our social space. So, perhaps a better way to think about it is this: Social Software is the programming of the space between people.
Comment for William Grosso’s weblog: On Becoming an Open Source Person: i agree with you that there are two developer camps. But i define the camps a little differently. The first side is the propriety world (which includes Microsoft and their .Net, as well as Sun ONE Java). The other side is the open source world. The world of the proprietary aims to design and build and control the system from the top down. They have a firm belief that this makes software better. The open source developer camp aims to do just the opposite. To design and build and not at all control the whole system, because we equally have a firm belief that our development environment is the...
the XMLeditor continues... we've extended the xpath matching to understand this kind of query: /projects/project[@node='someProject']/files/file[@id='123'] i know it's a pretty simple requirement, but then we never set out on this project to fully support xpath. Perhaps one day we will. But for now, this is simply meant to be a simple interface to editing data. The rules are, you can only edit one node (and all of its children). children which you want to not edit can be hidden in either a hidden textfield, or else an invisible textarea (for complete nodes). our example has also pushed us to edit different parts of a node on different screens. i think once we get this next stage complete, our biggest challenge...
the XMLeditor has been really interesting to work on lately. it seems to combine all of the approaches to parsing xml using an event parser, which alan and i have been exploring. Ultimately, we found trying to do several things at once became too complicated. So the model is now simplified to working one node at a time. Given our pseudo xpath, we can locate any node we want. We can return either the whole markup for a list view, or else just the fragment. We can take that fragment, build our xhtmlform structure and that is now editable, by simply replacing the old node with the new node. Delete is a case of replacing the old node with nothing. ...
Software documentation is one of the missing pieces of the software game. So many systems are not well documented. It's also not really part of the budget of most systems. The client certainly doesn't want to spend time on something so abstract. They don't really understand why a system needs to be documented. i do agree that this is an aspect of software development which is lacking, however i think the solution is not in more and better documentation; i think the solution is in better systems. Recently, i spent a little time thinking about how to enable development of an open source system i am working on (cln). There were a few things i decided to do to help...