Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

cms:begin_document [2013/05/31 16:20]
suitable [Introduction]
cms:begin_document [2013/05/31 17:53] (Version actuelle)
suitable
Ligne 5: Ligne 5:
 What would an ideal system for collaborative document sharing be like?  In particular, what might an individual want to have for a family site, or a college class site, or a personal site?  Can a same system satisfy all those wants? Is one technically feasible? What would an ideal system for collaborative document sharing be like?  In particular, what might an individual want to have for a family site, or a college class site, or a personal site?  Can a same system satisfy all those wants? Is one technically feasible?
  
-The past decades (yes!) have provided many opportunities to use various computerized systems for producing, sharing and modifying what may generically be termed [[:documents|documents]].  These may be **push** systems such as electronic mail and instant messaging; **pull** systems, such as web sites of various sorts; or systems which are both, such as mailing lists with archives to consult and web sites with RSS or Atom feeds.  Another aspect of differentiation of systems is access control, whether to publish, to consult, or to respond: who can send, who can be allowed to read or prevented from reading, are comments allowed with or without moderation, is identification required or is anonymity allowed.+I've had this web site for a few years and I'm wondering what to do with it.  I originally expected it to develop non-hierarchically and non-linearly (maybe like [[http://everything2.com/|e2]]), and believed a wiki engine would have less influence on the content than some alternatives.  Blog engines, for instance, publish sequential notes and tend not to provide controlled access to publications; school notes and project reports and such needed some re-ordering--and co-authoring-- and could only be shared with classmates, instructors, and so on, so using a blog for that would have been challenging. It has turned out, though, that it is mainly hierarchical, due to use for school but not only.  Other publishing systems, such as [[http://www.spip.net/|spip]] have some fine features for publishing with a little workflow management and translation management, but no access control once content is published (unless I missed it, or it has been added in the past few years). 
 + 
 +The past decades (yes!) have provided many opportunities to use various computerized systems for producing, sharing and modifying what may generically be termed [[cms:documents|documents or resources]].  These may be **push** systems such as electronic mail and instant messaging; **pull** systems, such as web sites of various sorts; or systems which are both, such as mailing lists with archives to consult and web sites with RSS or Atom feeds.  Another aspect of differentiation of systems is access control, whether to publish, to consult, or to respond: who can send, who can be allowed to read or prevented from reading, are comments allowed with or without moderation, is identification required or is anonymity allowed.
  
 These experiences have revealed a large range of problems and questions, many of them unanticipated, at least by many users.  They have given rise to a vast portfolio of intellectual property contracts for software, documentation, and other original content.  They have drawn attention to the difficulty of ensuring privacy, limiting distribution, and retracting publications.  Each of these topics merits an essay (or more), but treating these questions is beyond the scope of this note. These experiences have revealed a large range of problems and questions, many of them unanticipated, at least by many users.  They have given rise to a vast portfolio of intellectual property contracts for software, documentation, and other original content.  They have drawn attention to the difficulty of ensuring privacy, limiting distribution, and retracting publications.  Each of these topics merits an essay (or more), but treating these questions is beyond the scope of this note.
- 
-I've had this web site for a few years and I'm wondering what to do with it.  I originally expected it to develop non-hierarchically and non-linearly, and believed a wiki engine would have less influence on the content than some alternatives.  Blog engines, for instance, publish sequential notes and tend not to provide controlled access to publications; school notes and project reports and such needed some re-ordering--and co-authoring-- and could only be shared with classmates, instructors, and so on, so using a blog for that would have been challenging. It has turned out, though, that it is mainly hierarchical, due to use for school but not only.   
  
 For various reasons((Dokuwiki developers continue to add features.  I'm not sure I need new features.  Everybody has to have AJAX search boxes now, but is it really necessary? Is jQuery required? With each update, there are backup copies to make, tests to run, sometimes changes to make in CSS...so I tend to put off doing them.  AFAIK, Dokuwiki does not have "save as draft" and some user management features I'd like, which I'll say more about further along in this document. )), I'm wondering whether I want to continue to use DokuWiki to manage it, find something else, or try to write my own site management system ((Yes, I have some idea what that entails. Four of us built a smallish, specialized file submission system with limited workflow as a school project a couple of years ago.))  I suppose I'd like something like a **non-push** email, wherein I could save drafts, //send// to the whole world (or to lists of my choosing) but only if they come read.  For various reasons((Dokuwiki developers continue to add features.  I'm not sure I need new features.  Everybody has to have AJAX search boxes now, but is it really necessary? Is jQuery required? With each update, there are backup copies to make, tests to run, sometimes changes to make in CSS...so I tend to put off doing them.  AFAIK, Dokuwiki does not have "save as draft" and some user management features I'd like, which I'll say more about further along in this document. )), I'm wondering whether I want to continue to use DokuWiki to manage it, find something else, or try to write my own site management system ((Yes, I have some idea what that entails. Four of us built a smallish, specialized file submission system with limited workflow as a school project a couple of years ago.))  I suppose I'd like something like a **non-push** email, wherein I could save drafts, //send// to the whole world (or to lists of my choosing) but only if they come read. 
  
-Since starting this site, I've also had some formal training and education in software engineering, learned a bit about composing documents with LaTeX, started using emacs org-mode. I hope all that will contribute to my doing a better job of the rest of this note. Idealized design (or idealized re-design) refers to a planning and project management framework proposed by Russ Ackoff, in which the starting step is to imagine the most ideal possible state or solution possible with proven technology, then finding a way to achieve it. It deserves an article, but is of general interest so will not be further treated in this note but [[idealized_design|elsewhere]].+Since starting this site, I've also had some formal training and education in software engineering, learned a bit about composing documents with LaTeX, started using emacs org-mode. I hope all that will contribute to my doing a better job of the rest of this note. Idealized design (or idealized re-design) refers to a planning and project management framework proposed by Russ Ackoff, in which the starting step is to imagine the most ideal possible state or solution possible with proven technology, then finding a way to achieve it. It deserves an article, but is of general interest so will not be further treated in this note but [[planning:idealized_design|elsewhere]].
  
 ===== Table of Contents ===== ===== Table of Contents =====
  
-  * [[|People]] +  * [[cms:who|People]] -- description of use cases, privacy, trust, community dynamics.  
-  * [[|Usability]] +  * [[cms:how|Usability]] --  
-  * [[|Types]] +  * [[cms:what|Types]] --  
 + 
 ==== Terminology ==== ==== Terminology ====
  
 
cms/begin_document.txt · Dernière modification: 2013/05/31 17:53 par suitable
 
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki