On 11/04/2007, at 10.07, IOhannes m zmoelnig wrote:
Steffen wrote:
On 10/04/2007, at 22.51, IOhannes m zmoelnig wrote:
Yes, the idea was as Hans said with only the one addition that in the /community/projects/exhibition there is not only documentation but also the organization (the schedule for example) of the project.
yes i am aware of that, and i think this is the way to do it. however it does not convince me that there needs to be an extra /exhibition space separated.
Since there is more in there then documentation i don't think it should live in /docs/.
yes i totally agree here. as said before i am no big fan of the /docs section anyhow (as far as it is not concerned with "3rd party" documentation like pddp or pdb) i do think that content and documentation of this content (and organization of this content) should stay as close together as possible.
Since it's not dev like, but rather really is a community project, i found that hosting the documentation and organization bits in / community/projects/ was quite (and most) natural.
yes i agree too.
I am aware that this argument bit it self in it's tale as then the "output", the actual exhibition, should "naturally" also live in / community/project/. But, as argued in the proposal (or was it one of the email that lead to the proposal), that would be hiding the exhibition too much (to my taste). If this exhibition project succeed I really think it will be very valuable addition to the Pd community.
yes of course. the question is, why /community/projects/exhibition is "hiding". is it because of the ease of typing? (http://puredata.info/exhibition vs http://puredata.info/community/projects/exhibition/current) of is it for making it prominent on the start-page? so people will easily find the link (no matter how complicated)
Right. I'll round these comments/questions up in on go as they much connected in my view.
There is two questions: Why separate and why "hidden".
Let me use a metaphor: The gallery down in Smart-street. It has a front room and a back room. The front room displays the art. And in the back room they poke there nose and make arrangements for the next exhibition.
- You have casted light on way to deal with that 'separation but in the same "house"' within this (plone) system below, and I'll get back to that below.
I then found that the back room naturally was to be located in / community/project, since, as I said, it is a community project, the / community/projects/ folder existed, to pay respect to other projects in there (I also don't move my home dir to the root of my hard drive) and to inspire other community projects.
I've realized that this argument is not very strong as most thing on puredata.info is in fact community projectsm and (to use modus ponens right) they that do not all live in /community/projects/. Hence a community project need not live there. And to be concrete, the Exhibition project could live entirely in /exhibition. (Or the community projects that don't live in /community/projects/ should be moved in there - but leave that).
Left is the hiding part. Why can't the front room be placed in the / community/projects/exhibition/ folder. Both your suggestions are right, they go together. I think. That may sound spoiled? But i think it is an appropriate place to place an exhibition on a community site. It is commonly seen on other web sites.
That said, it would be interesting if you could convince me why it should not be separate. You best argument is in the span between 'you think' and my lacy of solid argument for. Please don't take this bad.
That is why i found that putting the actual exhibition closer to documentroot would be o.k. even when the documentation and organization parts would live in /community/projects/ since "closeness" to that "position" adds to the value of the project.
i am not sure whether i understand this.
I hope it is now clear given the above explanation? It was just what you suggested about the hiding part. If the exhibition is placed in / some/odd/place/on/the/community/site/ i think it spills some of it's potential. Since putting it close to doc-root also make it more "official" which is a good thing when you display work that can be done in (this case) Pd.
Another reason is that pulling forward what can be done in Pd will make it easier to find for new/potential users. If there is something such folks want to see then it is examples, and it's got to be right up there face. "There's no screenshot link from the menu, oohhh noooo. I ditch this Pd right of the bat." It a kind of psychology that is frequent used in both marketing and teaching environments. One have much limited time to get the basic or essential idea though (or sold). Do you make it in that time there is a chance they come back for more knowledge/goods.
It's of cause subject to debate if that is a right thing to do.
[snip] just to make sure that this is clear: i am in no way opposed to the way you organize this (and the fact that you do organize it). i am just wondering whether there are ways to streamline the workflow.
i have not said all this as a reply to your original proposal, since i don't think that this discussion is _that_ relevant; i think it rather likely that such discussion would have stopped the process of getting this exhibition done rather than fertilized it. however, now that there is some work going on i would like to settle this minor issue.
Thats all fine, IOhannes. I don't take it hard. I'm open to discuss things (openly). And I also just want the best and believe it can be done though (open) collaboration.
And yeah. I think you are right that it would not have fertilized this project, if it was brought up as a reply to the proposal. Since it then would have been a rejection due to the (lazy) consensus procedure.
I just tried to be as explicit as possible in the proposal to make it happen. I thought that was needed since most of the other ideas have died out.
developping things in /com/proj/exh/vol-#/ and then moving them to / exh/ (or was it /exh/vol-#?) just seems to be a kludge.
Agreed. But they are to be build into /exhibition/vol-# if possible,
the question is: what do we really want and what do we do because we think this is the simplest way to make it work.
True.
the way we have to work(around) with computers changes our way of thinking. this often leads to solutions that are sub-optimal as they are dominated by the way we might get the thing done rather than the way we want the thing to be done. (obviously i am within the same system so i might well do the very same in the following paragraphs; please tell me about the beam in my eye)
True.
i believe that this is what the proposal is about:
- having an exhibition on a prominent (easy to find) spot
- having an archive of all exhibitions
- being able to do all organisatorial stuff (of creating new
exhibitions and maintaining the old ones) online (independent of the place you currently are and who you are (community concept)
- doing everything with minimum amount of work (no duplication of
work!)
Basically. Yes.
having the /exhibition place is clearly in fullfillment of the 1st item in this list. all the rest can happily live in /comm/proj/exh.
duplicating the content to the 2 folders OR moving it from one folder to the other OR separating content and organization into 2 folders, is imho only a way to achieve all items in the list.
True.
however, i think that this is prone to errors and dead-ends (it is easier to maintain one place than two places however close they are), hence this email.
O.k.
we could also achieve all items in the list if we have a way to make a prominent place (e.g. "/exhibition") be the SAME thing as the to-be-published exhibition (whereever it resides) AND to make sure that the casual visitor is not disturbed by things they are not really interested in (e.g. organizational stuff)
O.k. As said above, I'm (now) o.k. with moving the documentation and organizational stuff to /exhibition given such behavior.
plone provides ways to acchieve both: "hiding" things can be done by the work-flow (which is currently totally unused in the puredata.portal; but there are really 3 states "private" (only the owner of the object can see it), "published" (everybody can see it) and "visible" (which currently is basically the same as "published" (apart from the color) but really can be made into "visible for members only" (e.g. all people that are currently logged in)) therefore we could have the entire documentation and organisation just besides the real exhibition without worrying about having to tidy up the exhibition space.
That would be o.k. Kind of similar to hiding the folders as / exhibition/files/ are now. But better since members can then find the documentation. They now can't find the files folder, i think, but they know it's there be cause it says in the docs. Or maybe they can just use the "view content" feature? But that would be dodgy.
one problem is, that WikiPages are outside of the standard workflow (you cannot set them "private" or "published"); i do not see a real reason why the exhibition should be based on WikiPages (there are 3 main features of WikiPages over ordinary 'documents': "everybody" can edit (not a real _feature_ considered we are talking about a curated exhibition), easy markup language (but you can use StructuredText in ordinary documents as well) and easy subpage creation (not relevant if each exhibition is restricted to one singe page)
That is true. However, the wiki pages are already not displyed in the menu as all non folders or smart folders don't get into the menu.
Also the documentation and organization part need be wiki such that all can alter and add to them. So those bits don't get into the menu as "viable for for members only" anyways?
A sketch of how it would be then. This is what i would like, if the org+docs are to be in the same folder as the exhibition (ie in / exhibition).
Some files are subject to change as mentioned in the update email. It is generated by 'tree'. The dots are therefor the usual hidden for normal 'ls'. Hence used here as a metaphor for "public" and "visible for members only". The vol-# should however not take up space in the menu. Thats what's the archive is for. The archive makes sure only old, hence not to-be, exhibitions are on display. And can hold descriptive information (think program notes).
exhibition/ |-- .files/ | |-- vol-1/ | |-- vol-2/ | `-- vol-3/ |-- .organizing |-- .schedule |-- .template |-- about |-- archive |-- submission |-- vol-1 |-- vol-2 `-- vol-3
Does it makes sense?
making to links appear the same is a bit more tricky. to repeat my last emails there are basically to ways to do it:
- the simple way: make a prominent link (e.g. an "exhibition" tab) on
the main-page that really points to the current exhibition.
- the harder way: make an equivalent of a symbolic link (this is: the
/exhibition IS the current /exhibition)
btw, making a _WikiPage_ ./exhbition/vol-# to be the default instead of ./exhbition/FrontPage is really rather simple.
What is the difference between that "rather simple" way and the "harder way"? I don't see it. The simple way i think is to choose the "display -> Change the item used as default view in this folder"? But choosing that leaves me with nothing to choose between, as mentioned before. I get: "There are no items in this folder that can be selected as a default view page."
however, if the exhibition would be a directory ./exhibition/vol-#/ this would be harder to make the default view for the root (./ exhibition), so it might well be worth the effort to spend some time to make a "symbolic link" feature work.
Yes. Folders like that is not needed. Hoping I'm not blinded by the "system". I admit i don't know much about how it works. Why help like this is much appreciated.
uäh, a long email; i am not sure whether i would read it myself ;-)
Hehe. Then you might not read this, since i now made it longer 8-)
best, steffen
PS:
PS. IOhannes, i've just been hitting reply-all; wasn't meaning to sent the email(s) specifically to you. You just happened to be about. I though the mail list software too care to multiple emails. Or is another matter?
no problem. sorry if my rant was on a too prominent place of my last email.
Cool. I just wanna do it "right".