[Pdweb] Exhibition Update

[Hans-Christoph Steiner]

You guys lost me there... that's just too much. :)  All I have to say  
is that Steffen has a good plan, let's let him finish it, then we can  
see how it works and give feedback.  Nothing is immutable.  But even  
a bad exhibition page would be better than none at all, and too many  
Pd initiatives have been lost because of too much list discussion.   
(That said, I don't think this is going to be a bad at all).

That's my two bits.

.hc



On Apr 11, 2007, at 9:15 AM, Steffen wrote:

>
> 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".
>
>
>
> _______________________________________________
> pdweb mailing list
> pdweb at iem.at
> http://lists.puredata.info/listinfo/pdweb



------------------------------------------------------------------------ 
----

                   ¡El pueblo unido jamás será vencido!