Our Culture /
Vision
Difference (previous author)
(Change, Edit, normal page display)
Changed: 1c1
AndriusKulikauskas: Here's a page for thinking through our vision of how we might best use ProWiki as a wiki engine supporting a variety of functions and technologies for the activity of the MinciuSodas laboratory and related networks.
|
Added: 2a3
Added: 3a5,12
Here's a page for thinking through our vision of how we might best use ProWiki as a wiki engine supporting a variety of functions and technologies for the activity of the MinciuSodas laboratory and related networks.
I'm using the ProWiki engine for four different kinds of interfaces:
* FormatFree
* Questionnaire
* SimpleWiki
* FractalWiki
|
Changed: 131,181c140
Helmut, thank you for your message to me at OurCulture. Yes, I think MeatballWiki is a good place for this and I will set up one or more pages there. Currently, my focus will be on part "B" I describe above. I'm thinking that ProWiki pages are stored in a format for which I could build a simple interface that would structure and present the page as a collection of textboxes (marked by page sections) and metadata boxes (marked by variables). So I could create an interface that could operate on ProWiki pages, a sort of AmateurWiki. Do you think that would be very complicated or not? If I could build something in 20 to 40 hours for editing pages="questionnaires" that would be excellent for many of our needs, I think.
Andrius, we have a number of components and plans in that direction to support this in ProWiki. Basically CdmlForm can be extended to get/put its data from/to the page, like you describe. An options like <n>EditForm=Admin/FormForHomePage</n> could control that. I also think that we need a simpler, special syntax to routinely define these forms. From other wiki applications (reported at WikiSym2005) we know that a similar form may be needed to display the data. Could this a FeatureRequests/FormEditing that we specify and implement together in reasonable time, fill your needs? -- HelmutLeitner September 9, 2006 8:22 CET
Helmut, That would be excellent if this might be a feature request, but especially as you have already worked in that direction. At the heart of my request is to be able to have a form-driven interface for use on any wiki page including both new and existing pages. Each variable would have its own textbook and so would each section. And it would be good if this might work as a questionnaire, with questions and answers. I suppose for each metadata variable we could associate a question. And I suppose that a section's "question" would equal the title of the section. I imagine this to be a substantial bit of work and am glad that you have done quite a bit and might continue. I would also like to learn enough about your file structure to see if I could operate on it directly. I see the .db file structure and in principle it is straightforward enough to read and to present as an HTML form, and likewise to write back to the file. I suppose it's a little more tricky to preserve as you are the file changes, but perhaps that too is straightforward enough. Although you have already developed most of the tools for this. As a side note, yesterday I spoke with a potential client/sponsor for work on a website for a community much like ours and I would focus on this type of functionality in three formats: A) profile forms in their content management system, B) editable single ProWiki pages as above, C) email driven questionnaires as in Thomas Kalka's social ping system. I said I would do at least one but hopefully all three, it would be a loose arrangement, my work for them. My feeling is that these three are esentially the same and, for example, ProWiki could be used as the engine for storing and maintaining the information, or at least, as one of the formats. I asked for 500 USD per month for 5 months which would include other duties. So I didn't factor any budget for you but I would either do this myself and contribute that to ProWiki or, if you can help with some of this, do something else that would be useful for you. Also for this work I'm interested to write a general proposal and approach businesses like Yahoo if they might contribute and then I would want to include you in the budget. Anyways, I'm alerting you so that you might think and keep me straight, too, regarding your best interests. Thank you for all your help!
Andrius, don't worry about money issues. I don't expect to get paid for this, because something like this has been in my development backlog for many months. If you have enough time let's talk what ProWiki can contribute, I can implement that, probably within a few weeks. Then you can still consider filling needs still open by external programming. BTW does Thomas have his "social ping" already in place? -- HelmutLeitner September 11, 2006 9:58 CET
Helmut, Thank you. I think Thomas hasn't started yet, I need to get back in touch. Also, I'm thinking that for my purposes it's relevant to have an API for the "simple editable page" much like you have done for the metadata. What I mean is to be able to "read" a .db file perhaps as an object with sections (titles and values) and variables (values) and also to be able to "write" to this object. Then it would be possible to call this object from an HTML page which is not associated to the wiki. This means that we could have simplified wikis, even single page "wiki atoms", using the ProWiki object format, and that encourages interoperability with other wikis, too. We could assume for the beginning that the text does not have any wiki syntax (aside from sections and variables) or simply shows the syntax if it does (as in edit mode).
Andrius, if I understand it correctly than it is intrinsic for you to have a separate API to access and use wiki as a kind of "database". This sounds like you want to become more flexible to realize your ideas, e. g. by using PHP or C or another language of your choice. This is possible and I can provide information about data formats and internal protocols or procedures. But in programming this you are on your own. There are many issues involved (page revisions, logging) that, if done cleanly, are "lot of work". I wouldn't want to add a lot of work of mine to support you solving problems on this way. In addition, I can not guarantee stability of all involved implementation detail. So a future release might break some of your code and enforce additional work you are not prepared to do at that point of time. It's no advantage for the ProWiki project to have you accessing ProWiki file structures from the outside and I have to assume that your programming will not be fully open, as smaller projects, done on the fly, rarely are. So this programming will improve your specific enviroment, but the work will not be fully reusable and available to others, although this isn't the way you usually go about "open source". Maybe I misunderstand you, but all this starts to sound rather complex and not the "step-by-step" way we usually go in developing socio-technical wiki systems. -- HelmutLeitner September 12, 2006 9:41 CET
Helmut, yes, when you find time, please make available information about the file structure. Then I can program what I want. I will start with the ability to change the wiki page text and the metadata. It seems this is stored at the top of the .db file. I won't worry about page revisions, logging, etc. until that matters. AndriusKulikauskas September 12, 2006 10:50 CET
Andrius, the page content is the .dw file. The .db file contains a key/val hash of metadata joined with the 2-char-separator "\xb3" and "3", no order of keys. -- HelmutLeitner September 12, 2006 11:08 CET
Helmut, Thank you. What are the consequences if I simply edit the .dw file programatically? Is it possible to update the .db and .txt r files somehow afterwards? It would be very useful for me if I could simply edit the .dw file programatically and the PmWiki engine could take care of the rest. Whereas I could worry myself how to deal with the .dw text. Andrius
Andrius, the text of the page will show correctly, diffs, authors, change date and other information will be out of sync. Parts of this information are just lost, other parts might be reconstructed. Anyway this is where the un-fun work starts and you are on you own. -- HelmutLeitner September 12, 2006 15:38 CET
Helmut, it's good to know that the text will work fine. That means that for new pages there should be no problems. So that is enough for me for now. However, I'm wondering whether it's possible to have a Perl function to which I could feed the content of the old page and new page and then the ProWiki page engine would take over. How does ProWiki update pages currently? I suppose it also reads in the author name and the time. AndriusKulikauskas September 12, 2006 16:24 CET
Example code to find the relevant functions:
[[Code]
sub PageSetTextLogSummary {
my ($id,$newtext,$logflag,$summary)=@_;
my ($oldtext,$diff);
RequestLock();
$oldtext=PageRetTextFast($id);
$diff=TextTextRetDiff($oldtext,$newtext);
my $rev=PageSetTextAuthorMinorDiff($id,$newtext,1,0,$diff);
CacheWrite($id,$rev,$oldtext,$newtext);
if($logflag) {
my $user=RetParam("username","");
my $edittime=time;
RcLogWrite($id,$summary,0,$edittime,$CookieID,$user,$rev);
}
ReleaseLock();
}
]
--- HelmutLeitner
Helmut, Thank you! This is very helpful and encouraging. So I will start working on an interface for some very simple isolated pages, for example, for people's profiles or for collecting stories. And then as our collection grows I think it will be more clear how and why and where to integrate them into the wiki. As it grows I can try to integrate them better into the wiki using the above functions. Also, if the index is rebuilt, then that helps include any pages I may have created programatically, yes? I'm curious what is the effect of rebuilding the index. I forget, too, how the metadata lists get rebuilt. [--Andrius]
Andrius, metadata are updated as part of <n>CacheWrite</n>. -- HelmutLeitner
|
AndriusKulikauskas: Helmut, as you suggested, I'm moving discussion of our OurCulture wiki to  an OurCultureWiki page at MeatBall wiki.
Older Thoughts
Here's a page for thinking through our vision of how we might best use ProWiki as a wiki engine supporting a variety of functions and technologies for the activity of the MinciuSodas laboratory and related networks.
I'm using the ProWiki engine for four different kinds of interfaces:
I'm realizing that by thinking of ourselves as technology evangelists we
may arrive at a natural organization of ourselves in terms of large and
small teams. Indeed, there is a need for a path by which a team can
grow from a single person like Dr. Rod King's
http://www.idealsolutionsmanagement.com Fractal User Interface to an
entire community such as Rick Nelson's SolaRoof http://www.solaroof.org
or even Christopher Alexander's Pattern Language movement. And along
the way the team grows complex and differentiates itself. We can help
encourage this team building process. I think it helps to realize from
the start that the teams are of very different sizes and at very
different stages. Correspondingly, in each domain our knowledge grows
and evolves. And it becomes more clear what kind of projects are
relevant for each team and what kind of intercoordination is helpful.
This also suggests a "working-in-parallel" that will help us realize
what expectations should we share so that we can truly support each
other as independent thinkers. What are the values that make our
technologies better than "neutral", that make them wholesome, that have
them serve those who are ever marginalized? What is it about a
technology, a methodology, an evangelism that opens our heart to include
it? I think that, for example, it should encourage knowledge to be
available to all so that all might engage it. What should we be able to
expect? For example, I think that it's not helpful for us that
Christopher Alexander has copyrighted the architectural patterns in his
book "A Pattern Language" or that Edward de Bono has trademarked his
"six thinking hats" methodology. And I personally think that a
"copyleft" approach may, in many cases, be unhelpfully restrictive and
inappropriately legalistic. But what should we work towards and how do
we start with each technology? For example, Franz Nahrada and our
friends in Kirchbach, Austria have decided strategically that at this
time for video bridging we shouldn't wait for open source technologies
to develop but we should make good use of existing proprietary hardware
technologies and break ground in terms of usage. I understand and
support this approach, but how do we make sense of it? How can we tell
if a technology (whether it's nuclear power or giant windmills or
Microsoft Excel or Skype or the Google search engine) is helping or
hurting our vision of "global villages"? Or more practically, in what
directions do we support Dr. Rod King's Fractal User Interface or Rick
Nelson's SolaRoof or Christopher Alexander's Pattern Languages or KB5's
Video Bridges? How do we work to help these all flourish as open
technologies?
We'll want online tools that can match the simplicity and the complexity
of our teams. I look forward to seeing a central role for Helmut
Leitner's ProWiki http://www.prowiki.org as a wiki engine for our
projects of various sizes. We're making a list at
http://www.findbetterways.info of our technologies. I want to see a way
for us to adapt our wiki technology to projects of very different sizes
for different kinds of readers and writers:
- A) Creating "read only" pages using metadata that we keep at our wiki, as we are at: http://www.ms.lt/?thinker=Franz_Nahrada which makes use of data stored at http://www.ourculture.info/wiki.cgi?FranzNahrada
- B) Having super simple "editable" pages that serve a very focused purpose, such as for an individual to write about themselves, or describe a project they are working on, or a book review, etc. These should not expect wiki mark-up or wiki links or much formatting in general. Instead I think there should be a form that people fill out, perhaps selecting a question and writing out the answer, and being able to have several questions and answers on a single page, yielding wiki pages and meta data. Links where applicable would be treated as metadata, as answers to questions. I would like this data to be updatable by email using the social ping system that we've discussed with Thomas Kalka.
- C) Have a normal wiki for advanced users, but just a flat wiki for that particular project.
- D) Have an advanced fractal wiki (as we've set up now) that (I foresee) is used primarily for moving and interrelating pages amongst various projects.
I think that most of this can be done with the existing ProWiki engine,
it's a matter of us learning how to do this and perhaps creating B,
perhaps as part of Thomas Kalka's system.
Thank you to all at Cyfranogi (John Waters, John Rogers, Jon Cousins,
Samwel Kongere's interviews) who have been sharing stories about our
"money minds". http://www.ms.lt/?action=Experience I'm very happy that
these stories (vignettes, episodes, anecdotes) are capturing our first
hand experiences. These are the types of knowledge that I'd like to see
us contribute using the "simple editable pages" described in B.
(Perhaps this is a use for transLucid and TheBrain and related "atomic"
technologies?) I look forward to collecting more such first hand
accounts regarding our "living space minds" (what makes a building
alive), our "learning minds" (our learning styles and strategies). And
what kinds of "minds" are relevant for sustainability, for alternative
energy?
[17:24:11] ? On a side note, I'm working further on our lab's website and I'm interested to have a "simple editable page" technology
[17:24:19] ? that would be for "single page" projects
[17:24:44] Nancy White what is the difference between that and a wiki page?
[17:24:45] minciusodas and would look like a form with some fields for free text and some for metadata and all fields could be thought of as answers to a question
[17:24:55] Nancy White ah, so some structure
[17:24:58] minciusodas So the point is that it would be easier to work with than a wiki page.
[17:25:05] Nancy White to be useful to those not used to structuring a page
[17:25:07] minciusodas Yes, less intimidating, much more structured.
[17:25:13] ? Yes, it would not require any wiki social skills.
[17:25:25] ? But perhaps the underyling page would be stored as a wiki and run by a wiki engine.
[17:25:42] ? So it would be for wiki pages that may not use any formatting but may have some structure, metadata etc.
[17:25:50] ? Have you run across that?
[17:25:58] Nancy White interesting. So there could be an event form, a meeting notes form, etc??
[17:26:00] minciusodas I'm thinking of looking for sponsors who might like to see that built.
[17:26:07] ? Yes it could be per object type.
[17:26:11] Nancy White It reminds me of the templates built into PBWiki
[17:26:14] minciusodas For example, to have a page for a person they could edit.
[17:26:22] Nancy White (which are still a bit geeky for second wave adopters)
[17:26:26] minciusodas Or a page for collecting a "first hand account".
[17:27:05] ? I'm not quite sure how links would be handled best in such an environment.
[17:27:12] ? But perhaps as metadata.
[17:27:19] ? Or Wiki Words.
[17:27:30] Nancy White interesting. Mille would take to that idea.
[17:28:03] minciusodas The idea is to have people contribute to the system without being experts. But to have it all run by one wiki engine, we're using Helmut Leitner's ProWiki. So there would be four uses for the engine:
[17:28:32] ? A) Store and output metadata as called for by web pages such as we're already doing at http://www.ms.lt
[17:29:34] ? B) "Single editable pages" for the most fundamental of purposes of data collection. This could also be interacted with through email. Thomas Kalka has thought through a social ping system where lurkers would get monthly questionnaires that they could respond to. Or they could trigger the questionnaires whenever they wanted to update their information.
[17:30:01] ? C) These pages could sit within a simple flat wiki devoted to an isolated project.
[17:30:17] ? D) The projects could sit within a fractal wiki that could be distributed across a variety of domains.
[17:30:40] Nancy White I like the ping tghing on B. Helps keep the network a little more visible
[17:30:42] minciusodas The latter would be for admins who move projects around for the best context.
[17:31:03] ? Yes and B would help us in finding work which is why it's a priority.
[17:31:44] ? Maybe Yahoo would be interested in sponsoring work especially on B because it would show the value in lurkers.
Helmut: I think that CoForum offers quite a number of innovative features. I know ThomasKalka and have an active collaboration, e. g. with WikiNet , and we are discussing development issues every now and then. As an occasional contributor I'm also a user of CoForum and I'm aware of all developments and I intend to provide at least some of them in ProWiki when they are ready and there is enough need.
Helmut: I think that "... have decided strategically that ... we shouldn't wait for open source technologies" is somewhat misleading. There has been no decision. The project has about 5-6 frontiers that must be advanced independently. There are many components that are proprietary, like e. g. camcorders. Other components like the transition from video signal to MPEG-encoded internet data stream are in OS reach but not ready-to-use. Currently proprietary SONY hardware is used for this, but this is not a decision, but a temporary situation out of a lack of alternatives. This can change any month or in a few years. Of course the VideoBridge project will not wait with building critical mass and creating sample content and know-how, until a specific component is available in OS.
workgroup growth
Helmut: I think that DorfWiki shows nicely how different Topics and WorkGroups can be supported in ProWiki, also in their growth from very small beginnings.
Fractality
FranzNahrada: Fractal Wikis are supporting the "intimacy" of spaces also. It allows each and every individual and small group to follow their own special endavour within a larger context and to define Sub-rules.
information and discussion placement
Helmut: What I do see as a problem is the overall placement of knowledge and discussions. Usually they are put in the place at hand, where no-one will expect, seek or find them. The best example are my three contributions here. (1) CoForum collaboration should be better in a "technological development of ProWiki" or FeatureRequests section (2) explanation of VideoBridge should be at some subpage of  DorfWiki:VideoBridge and referenced and (3) WorkGroup (or multi-project) support in a fractal ProWiki environment is also a topic that deserves a separate space, probably as part of standard documentation.
There are other topics touched. For example to support a community as complex as OurCulture one will suggest to use a MediaMix. Is this ProWikiCentre the best place to dicuss this? - Probably not. This should be either done in OurCulture itself, if it very specific, or in neutral spaces like MeatBall where such a discussion can attract people from different community that share the need and offer insights.
Helmut, thank you for your message to me at OurCulture. Yes, I think MeatballWiki is a good place for this and I will set up one or more pages there. --AndriusKulikauskas
|
|
