P040300a: nfoWiki Diary & Job Jar

This is a running job jar and diary of items in support of the nfoWiki project.

Status	Date	Description





	2004-04-02	The use of a kind of InterWiki link might be valuable for cross-references between nfoCentrale sites and others. This would make it more clear when one or both are off-line as well. That leaves open the possibility of some automated resolution of such links. Meanwhile, there is simply the matter of a style to be shown in HTML, and we can figure out the InterWiki-ness of it later?
	2004-04-02	I have been thinking about nfoWiki requirements and need to create that as something to work on here too. I think requirements is a separate (sub-)project, or at least it has its own output.
	2004-04-01	After spending some time on CollabWiki and in exchanges with Murray, I now have way too much to digest. There are activities on other wikis and discussion lists to list. There are notes and materials to digest and organize. I must figure out where these show up as work product, and should they be additional projects or not.
	2004-03-19	I posted an inquiry about WikiText to Tools-yak and turned up a lot of material that I should embrace and build upon. John Sechrest and Gary Johnson had done a lot of analysis, and Bill Seitz provided a lead to some other work on Wikiness. Murray Altheim offered up his APT processor which he then saw how to make into a Wyki processor. We also went around on a magic line at the front, `#!wiki` and what it could have in it. Murray is looking at registering a MIME type for this stuff. I want to both adapt this material and also contribute to its being expanded on CollabWiki.
	2004-03-14	Don't forget that we have FrontPage extensions as a tool, if we want it, and also WebDAV in some cases. It would be useful to put that in somewhere.
	2004-03-14	Put analysis and research stages into the nfoWiki project first-round bootspiral.
	2004-03-14	Cull my blog for material of value in the fleshing out of the nfoWiki project analysis and research stage.
	2004-03-14	Clean up my blog and publish it so the recent material on Wikis is captured
	2004-03-14	Cull my e-mail folders and postings in various places into something that captures the recent exchanges, so the comments and inspiration from others is reflected and I begin to compile who provided inspiration for the ideas being developed here.
	2004-03-14	Sitting here typing blue (navy, I think) text in red (ish) boxes reminds me that I know someone for whom this combination is unpleasant. As part of accessibility, being able to alter the colors or theme of a presentation is important. Then there are the more serious accommodations beyond substitutions like that. It is already a practice to use fonts in a way that they can be resized by the browser at the user's option, and we have window resizing and scrolling automatically under user control by using HTML and browsers. Something to keep in mind as part of the exploration of accessibility that will be happening as a separate project.
	2004-03-14	Also with regard to loose and strict (below), I wonder what to call it when running with no net and only scaffolding. Bare-foot comes to mind (well, that was my second thought). Not even the shoemaker has shoes at the beginning in the bootspiral world. It's all pretty much fake but it is a way to put something into practice even though it is not really computer-mediated very much at all. The idea is to preserve the investment in early content as well as possible, even though the machinery is seriously under-developed. Also, upgrading can occur when the material is touched again using a smarter tool. This is an interesting view on legacies. I can see it applying to archived material in unalterable form too (because it is read-only, because it is signed or otherwise protected, and replacement would lose the provenance, etc.)
	2004-03-14	A pull-down that provides a lot of the Wiki-ness controls by menu selection would be useful. The use of toolbars is well-established with Wikis and Blogs, and that should be possible too. I should catalog those thingies as well, but it looks like some of this is going to have to split into a UI and HCI subproject.
	2004-03-14	With regard to loose and strict, I think I want to define WikiText strictly. Then I want an error-handling behavior that allows as much as possible, transformed to be strict, so that an user can see the consequences of their entries and have an opportunity to repair the result. There will not be diagnostics or any kind of intrusion, especially in the easy forms of WikiText. We don't want to get in the way. We also don't want to be inscrutable. This must be a coherent activity, and it must encourage formation of a successful conceptual model for the user having a successful outcome without much work. This is an area to discuss much more too. I think the way Blogger says there were some difficulties, and I can find out what they were might be useful. There should also be a good Help system for when an user wants to troubleshoot something. This is a dance that needs to be experimented with. The main trick is going to be not intruding on the user and also not making it difficult to notice that an exception has been dealt with and there is additional information.
	2004-03-14	There are a large number of features that processors like MediaWiki sneak in via NameSpace (e.g., User:, special:). I don't even know whether they support InterWiki references or it is all done by external references. I need to suppress the urge to introduce ~~much~~ any of this at the beginning, but I need to have a good idea about the principle to be applied, so that I can reserve the extension mechanism appropriately, first tacitly, then by how well-formedness is controlled.
	2004-03-14	I like the way MediaWiki will break a page into sections and add separate edit controls on the pieces. This is a lot like how blogs end up in fragments too, and then the fragments become editable. All it takes is to introduce a section-level heading and, after save, the split is made. This is very cool. Discuss does not have that granularity.
	2004-03-14	For a #!-signal line, the signal should not be presented in editing. One wants a way to be able to upgrade, but it shouldn't be something someone knows how to edit. The editor should present the text/plain WikiText in a form it is conditioned to accept. That is what the user will see and be able to edit. There are things that should be under the user's control in terms of (editable) format and such, just like choosing that sort of thing for e-mail, and it is something advanced users, not necessarily experienced-with-this-Wiki ones, can use. Familiar menus and such, relative to the platform (how much do browsers and local JavaScript processors help with this?) Don't want it to always look like windows. (Separate this into another topic.)
	2004-03-13	Create page on Wiki Benchmarking and Make citations for names of benchmarks, the key source pages, links to the projects, and a narrative or bullet points about what I like about it.
	2004-03-13	Go back to MediaWiki and fill in more on the WikiText Conventions.
	2004-03-13	The workings and value of a diff function need to be considered in the choice of WikiText and conventions about analysis based on what is what here.
	2004-03-13	Cull the Notes Diary for material that goes here too.
	2004-03-13	It is important to address accessibility in this context. I ran into something about that. I need to see what there is to capture it and see what else there is to do.
	2004-03-13	I was thinking about the presentation view versus the view an editor or author might have, in terms of menu bars, tabs, and so on. It would be nice to have a way to move among the views regardless of the personalization my cookie or account invokes by default.
	2004-03-13	Create a log of benchmarks, what I like about them, and why. I told Eugene Kim that his blog and the Collaboratory Wiki were benchmarks for me. There are also Wikipedia and what I like about it. Furthermore, there are all of the ones I have blogged that I should look at again. Also, the AsciiDoc site as another benchmark, my affection for tabbed pages, etc.
	2004-03-13	Create a provisional nfoWikiText that will be used for the first bootspiral. It must be describable using itself. That is the primary acceptability condition. There must also be enough to provide for versioning and recognition of a particular version. There will be ways to upversion without altering the interpretation of material. (This becomes a requirement statement. I should do the requirement statement, and have the provisional nfoWikiText characteristics as my supplier response to myself.)
started 2004-03-13	2004-03-13	Compile a collection of WikiText conventions.
done	2004-03-13	Cull the project job jar for items that are best handled here, now that it is here.
done	2004-03-13	Create this page under the placeholder for project P040300: The nfoWiki Project and customize it for this application.
done	2004-03-13	Oh boy. OK, I have been asking around and talking about WikiText with AnderBill, on Tools-yak, and also trying out ideas on CollaborationCollaboratory Wiki and Wikipedia. It is time I created a place for all that jazz.
started 2004-03-13	2004-03-11	I have some benchmarks for the blogging, collaborative writing Wiki, and such now. For one thing, I really, really like how Wikipedia works, and the number of things that have been paid attention to. This has me all stirred up.
started 2004-03-13	2004-02-28	AnderBill and I keep talking about a Wiki and a Blog with commenting (and whatever the cross-over solution is). I am keen on that, but I am reluctant to begin. That's a bigger spiral, yet there needs to be a fluid way to collect contributions and build up to something. It would be nice to have something in place when I start my M.Sc dissertation project in August too.
	2004-03-11	I want to spiral on blogging and wikis. I think there are two things to figure out. The first step is to make an ASP page in a laboratory folder and then see what I can do to run JavaScript from places not in visible sections. Then I want to see how to put data in a place on the server. I will obviously try this out on compagno first, and then move it to nfoCentrale when I am sure I have a safe version to demonstrate there. Two steps -- running scripts from somewhere else, and being able to park data somewhere (preferably else, and not dictated by the client in any direct way).
	2004-01-08	In talking with Bill Anderson about having some collaborative support here, even if only a shared private FTP directory, I realize that I can also treat that as part of the development of software-engineering methodology for nfoWare as well. That is, collaborative support enables software engineering practices as well as provisions for people commenting and annotating content and so on. [dh:2004-03-14 I found an open-source project that is creating software engineering templates and other materials. I don't remember if they looked at having a project framework that is web-based and that starts out by bringing up a site and customizing it for the project, basically turning it into the ISO 9000 repository, a history record, and even configuration management -- depending on the project. I need to go back and see what the fit is. This is another possible dissertation project, depending on having a sponsor willing to receive, evaluate, and apply it.][dh:2004-04-01: I found the GEMINI project out of an EU Software Engineering activity in Palermo, that is on SourceForge also, and falling flat. There needs to be an understanding of the difference and what might be possible.]