[Pdweb] Exhibition Update

[Steffen]

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".