Attached is a proposal to make a Pd exhibition space on the Pd community website.
If no objections, I presume the proposal is accepted by lazy consensus and the write privileges will be given.
In the proposal a "manager" is mention. I'd act as the manager at first.
Best, Steffen
On 13/03/2007, at 17.11, Steffen wrote:
Attached is a proposal to make a Pd exhibition space on the Pd community website.
If no objections, I presume the proposal is accepted by lazy consensus and the write privileges will be given.
Two weeks has past. Is that long enough? I hope there will be some kind of sign.
Best, Steffen
Steffen schrieb:
On 13/03/2007, at 17.11, Steffen wrote:
Attached is a proposal to make a Pd exhibition space on the Pd community website.
If no objections, I presume the proposal is accepted by lazy consensus and the write privileges will be given.
Two weeks has past. Is that long enough? I hope there will be some kind of sign.
should be long enough ... ;)
LG Georg
On Mar 28, 2007, at 4:04 PM, Georg Holzmann wrote:
Steffen schrieb:
On 13/03/2007, at 17.11, Steffen wrote:
Attached is a proposal to make a Pd exhibition space on the Pd community website.
If no objections, I presume the proposal is accepted by lazy consensus and the write privileges will be given.
Two weeks has past. Is that long enough? I hope there will be some kind of sign.
should be long enough ... ;)
Sorry to be so late on this, I think it also looks quite good. Looking forward to see it in action.
It's definitely long enough, I say this is a done deal. The next step might be getting the access rights you need from IEM on the website.
.hc
LG Georg
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On 29/03/2007, at 6.31, Hans-Christoph Steiner wrote:
On Mar 28, 2007, at 4:04 PM, Georg Holzmann wrote:
Steffen schrieb:
On 13/03/2007, at 17.11, Steffen wrote:
Attached is a proposal to make a Pd exhibition space on the Pd community website.
If no objections, I presume the proposal is accepted by lazy consensus and the write privileges will be given.
Two weeks has past. Is that long enough? I hope there will be some kind of sign.
should be long enough ... ;)
Sorry to be so late on this, I think it also looks quite good. Looking forward to see it in action.
It's definitely long enough, I say this is a done deal.
great (x2).
The next step might be getting the access rights you need from IEM on the website.
As I suspect IOhannes is in charges of 'Pd at IEM' I could maybe try to contact him directly if he doesn't follow this discussion. I'll give it a day or two.
Steffen wrote:
It's definitely long enough, I say this is a done deal.
great (x2).
right!
The next step might be getting the access rights you need from IEM on the website.
just to make this clear: the IEM hosts the server and i am responsible for it. BUT: giving you the access rights is something every "administrator" of the site can do, not just me; there are others, like wini and hans.
As I suspect IOhannes is in charges of 'Pd at IEM' I could maybe try to contact him directly if he doesn't follow this discussion. I'll give it a day or two.
so what am i supposed to do? i have created an "./exhibition" space, but whom am i going to give administrative rights in there? 1900 users have signed up for an account at puredata into. most likely several of them respond to the name "steffen". what is your username?
fmads.r IOhannes
On 29/03/2007, at 13.42, IOhannes m zmoelnig wrote:
so what am i supposed to do?
In short, what I'veporposed/asked for wrt the "server" is write access to the following folders:
./exhibition/ ./community/projects/exhibition/
(details in the proposal)
and a email alias/forward to me (this sender address) named (exhibition@<pd-community-domain>).
If the later is out of the question, I can make a, say, gmail account. But I'd rather have that alias because of the looks and the relation to the site that actually will host the exhibition.
Note that write access and email alias are subject to chang when someone else take over the organizer role. - I'm not running way, just stating.
i have created an "./exhibition" space, but whom am i going to give administrative rights in there?
Cool.
1900 users have signed up for an account at puredata into. most likely several of them respond to the name "steffen". what is your username?
Sorry. My username at the community website is stffn.
Steffen wrote:
On 29/03/2007, at 13.42, IOhannes m zmoelnig wrote:
so what am i supposed to do?
In short, what I'veporposed/asked for wrt the "server" is write access to the following folders:
./exhibition/ ./community/projects/exhibition/
ok
and a email alias/forward to me (this sender address) named (exhibition@<pd-community-domain>).
ok (i have set this up and additionally directed this email to the new address)
Note that write access and email alias are subject to chang when someone
the former is simpler to manage (directly via the portal) to change the email-alias (currently) ssh access is needed (which is suboptimal, as it involves necessary interaction by the iem people)
nevertheless, it's ok for now.
one thing that comes to my mind: once there was a DoS-attack to puredata.info via SMTP. i temporarily closed port:25 (since it was not needed anyhow), but it is now open again.
else take over the organizer role. - I'm not running way, just stating.
Sorry. My username at the community website is stffn.
basically my email was just a rant about not knowing which user we are talking about.
anyhow: i have now (mis)used the "reviewer" group to also be "curator" of the portal. so any members of this group have special privileges in the 2 exhibition folders (apart from being reviewer on the rest of the portal)
being reviewer adds a little extra work: whenever a user "commits" a page to be published, the reviewer(s) get a notification and can really publish this content (at their own will; they can also just ignore the request).
tell me if everything works as expected, especially adding a wikipage.
(btw, what is wrong with wiki-pages being called FrontPage? this is just as standard as an html-page being called index.html)
mfgasdr IOhannes
On 29/03/2007, at 16.09, IOhannes m zmoelnig wrote:
Steffen wrote:
On 29/03/2007, at 13.42, IOhannes m zmoelnig wrote:
so what am i supposed to do?
In short, what I'veporposed/asked for wrt the "server" is write access to the following folders:
./exhibition/ ./community/projects/exhibition/
ok
and a email alias/forward to me (this sender address) named (exhibition@<pd-community-domain>).
ok (i have set this up and additionally directed this email to the new address)
Note that write access and email alias are subject to chang when someone
the former is simpler to manage (directly via the portal) to change the email-alias (currently) ssh access is needed (which is suboptimal, as it involves necessary interaction by the iem people)
nevertheless, it's ok for now.
Thanks for setting it up!
one thing that comes to my mind: once there was a DoS-attack to puredata.info via SMTP. i temporarily closed port:25 (since it was not needed anyhow), but it is now open again.
else take over the organizer role. - I'm not running way, just stating.
Sorry. My username at the community website is stffn.
basically my email was just a rant about not knowing which user we are talking about.
I hope it is clear enough now.
anyhow: i have now (mis)used the "reviewer" group to also be "curator" of the portal. so any members of this group have special privileges in the 2 exhibition folders (apart from being reviewer on the rest of the portal)
being reviewer adds a little extra work: whenever a user "commits" a page to be published, the reviewer(s) get a notification and can really publish this content (at their own will; they can also just ignore the request).
I don't feel i totally understand this. Maybe due to my lack of knowledge of the wiki system. I hope it comes.
tell me if everything works as expected, especially adding a wikipage.
I can create wiki pages and the emails get through. So that's good. I will properly have more questions about things. I hope to solve things along the way.
(btw, what is wrong with wiki-pages being called FrontPage? this is just as standard as an html-page being called index.html)
Did i say that? I don't know that standard, but i guess it's ok. What i may have said in a former email was maybe about having a headline/ header called FrontPage in all folders. It would be like haveing the first headline in each chapter in a book called \Begin{Chapter} instead of something that relates to the content of that specific chapter. IMO.
On Mar 29, 2007, at 7:42 AM, IOhannes m zmoelnig wrote:
Steffen wrote:
It's definitely long enough, I say this is a done deal.
great (x2).
right!
The next step might be getting the access rights you need from IEM on the website.
just to make this clear: the IEM hosts the server and i am responsible for it. BUT: giving you the access rights is something every "administrator" of the site can do, not just me; there are others, like wini and hans.
I didn't realize that I had admin access to the site. I am not sure I know what to do with it anyhow. Thanks for setting this up, IOhannes, I am looking forward to having this section setup for sure. I am sure others are too.
.hc
As I suspect IOhannes is in charges of 'Pd at IEM' I could maybe try to contact him directly if he doesn't follow this discussion. I'll give it a day or two.
so what am i supposed to do? i have created an "./exhibition" space, but whom am i going to give administrative rights in there? 1900 users have signed up for an account at puredata into. most likely several of them respond to the name "steffen". what is your username?
fmads.r IOhannes
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------ ----
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
I've made a "under construction" FrontPage wiki in ./exhibition. It includes contract info and a lill' about text. This is done such that eventual visitors though the main menu don't enter a dumb/mess.
Further "setting up" is, obviously, in the pipeline.
Yay, progress!
.hc
On Apr 4, 2007, at 1:29 PM, Steffen wrote:
I've made a "under construction" FrontPage wiki in ./exhibition. It includes contract info and a lill' about text. This is done such that eventual visitors though the main menu don't enter a dumb/mess.
Further "setting up" is, obviously, in the pipeline.
------------------------------------------------------------------------ ----
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
On 05/04/2007, at 5.55, Hans-Christoph Steiner wrote:
Yay, progress!
More progress.
As put in the proposal "internal" stuff is located '/community/ projects/exhibition' where as the "public" stuff lives in '/exhibition'.
I've edited the Organizing wiki page <http://puredata.info/community/ projects/exhibition/Organizing/>. If there are errors or unclearness, please correct it or let me know about it.
TODO:
- Next up is to make a "test" exhibition. This is both to make the Template wiki as well as to test that "public part" works as it should.
- After that i'll try to pitch Exhibition on the pd-list to make more people aware of it. Hopefully make some folks interested in being curators. In that sales pitch i'll include some possible exhibition themes to ease things up.
- Mean while i'll update the ToBeFrontPage <http://puredata.info/ exhibition/ToBeFrontPage> till it's nice (what ever that means), and the rename it FrontPage such that it will be the actual frontpage - ie the wiki page that the browser is directed to when pointed to the / exhibition folder. I curently can not manually point it to other wiki pages, hence not manually point it to a to-be-current-exhibition. This might involve wee changes to the dir layout in the '/exhibition' folder. If so I'll of cause let y'all know though here as well as edit the "What's Where" section of the Organizing wiki <http:// puredata.info/community/projects/exhibition/Organizing#ww>.
- Then it's go-go. People can add them self to take curator slots. And we see how it all goes.
Thanks for reading.
hi!
first off: i think it is time to put this thread on pdweb only and stop sending the same email as explicit emails too...
As put in the proposal "internal" stuff is located '/community/ projects/exhibition' where as the "public" stuff lives in '/exhibition'.
just one remark: what is the main reasoning behind this separation between /exhibition and /community/projects/exhibition? (probably i overlooked this in the proposal)
currently i see 3 possibilities for getting the "current" exhibition from /community/projects/exhibition/vol-# to /exhibition
1) copy the entire ./vol-# content into /exhibition (after cleaning it up first) -- bad because then there is the same content doubled in the portal possibly getting out-of-sync (even though this _should_ not be, but who knows...)
2) create an equivalent to a "symbolic link" from the "current" exhibition to /exhibition -- since plone does not support this by default, this would require an additional product to be installed
3) do not use the /exhibition part at all, but instead make a tab "exhibition" which points directly to /community/projects/exhibition/vol-# -- while this is ok to browse to (via click-click) it is not as good to remember.
all 3 ways are possible (just to make sure that my "buts" are not a "now that you have started i tell you it won't work"... ;-)), i was just wondering about the best way to do it. probably other plonistas can join in with better ideas.
mfga.sdr IOhannes
On Apr 10, 2007, at 4:43 PM, IOhannes m zmölnig wrote:
hi!
first off: i think it is time to put this thread on pdweb only and stop sending the same email as explicit emails too...
As put in the proposal "internal" stuff is located '/community/ projects/exhibition' where as the "public" stuff lives in '/ exhibition'.
just one remark: what is the main reasoning behind this separation between /exhibition and /community/projects/exhibition? (probably i overlooked this in the proposal)
currently i see 3 possibilities for getting the "current" exhibition from /community/projects/exhibition/vol-# to /exhibition
- copy the entire ./vol-# content into /exhibition (after cleaning it
up first) -- bad because then there is the same content doubled in the portal possibly getting out-of-sync (even though this _should_ not be, but who knows...)
- create an equivalent to a "symbolic link" from the "current"
exhibition to /exhibition -- since plone does not support this by default, this would require an additional product to be installed
- do not use the /exhibition part at all, but instead make a tab
"exhibition" which points directly to /community/projects/exhibition/vol-# -- while this is ok to browse to (via click-click) it is not as good to remember.
all 3 ways are possible (just to make sure that my "buts" are not a "now that you have started i tell you it won't work"... ;-)), i was just wondering about the best way to do it. probably other plonistas can join in with better ideas.
I think the idea is that /exhibition is the actual exhibition, while / community/projects/exhibition is the documentation. Perhaps it should be in /docs/exhibition.
.hc
mfga.sdr IOhannes
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------ ----
Hans-Christoph Steiner wrote:
I think the idea is that /exhibition is the actual exhibition, while /community/projects/exhibition is the documentation. Perhaps it should be in /docs/exhibition.
i do not understand this artificial boundary between exhibition and its documentation. what's the point of keeping them separate? wouldn't it be far nicer to make the exhibition be the documentation of itself?
mfa.dr IOhannes
On 10/04/2007, at 22.51, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I think the idea is that /exhibition is the actual exhibition, while /community/projects/exhibition is the documentation. Perhaps it should be in /docs/exhibition.
i do not understand this artificial boundary between exhibition and its documentation. what's the point of keeping them separate? wouldn't it be far nicer to make the exhibition be the documentation of itself?
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.
Since there is more in there then documentation i don't think it should live in /docs/.
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.
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.
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.
If it itches too much it (the documentation and organizing stuff) can be moved - of cause.
But it's not a technical reason that motivates it? The (re-)direct thing was 'from /exhibition to /exhibition/vol-#' rather then 'from / exhibition to /exhibition/FrontPage'. And also, the (re-)direct issue is not dead necessary but rather just nice-to-have.
Best, Steffen
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?
On Apr 10, 2007, at 5:19 PM, Steffen wrote:
On 10/04/2007, at 22.51, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I think the idea is that /exhibition is the actual exhibition, while /community/projects/exhibition is the documentation. Perhaps it should be in /docs/exhibition.
i do not understand this artificial boundary between exhibition and its documentation. what's the point of keeping them separate? wouldn't it be far nicer to make the exhibition be the documentation of itself?
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.
Since there is more in there then documentation i don't think it should live in /docs/.
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.
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.
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.
If it itches too much it (the documentation and organizing stuff) can be moved - of cause.
But it's not a technical reason that motivates it? The (re-)direct thing was 'from /exhibition to /exhibition/vol-#' rather then 'from / exhibition to /exhibition/FrontPage'. And also, the (re-)direct issue is not dead necessary but rather just nice-to-have.
That makes sense for now. Perhaps when people all know about the exhibition, it might make sense to move the purely howto docs to the / docs section and keep the Schedule and coordinating things in / community.
I am fine leaving it like this for now.
.hc
Best, Steffen
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?
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------ ----
kill your television
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)
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.
If it itches too much it (the documentation and organizing stuff) can be moved - of cause.
But it's not a technical reason that motivates it? The (re-)direct thing was 'from /exhibition to /exhibition/vol-#' rather then 'from / exhibition to /exhibition/FrontPage'. And also, the (re-)direct issue is not dead necessary but rather just nice-to-have.
hmm, probably i should re-read the entire conversation.
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.
anyhow:
developping things in /com/proj/exh/vol-#/ and then moving them to /exh/ (or was it /exh/vol-#?) just seems to be a kludge.
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.
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)
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!)
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. 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.
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)
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. 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)
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. 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.
uÀh, a long email; i am not sure whether i would read it myself ;-)
mfga.sdr IOhannes
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.
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".
hoping to shorten it...
Steffen wrote:
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.
i have seen so many sites becoming only partially maintained because the workflow of publishing was too complicated. that's the only reason. and to make it structured...so people can find stuff without resorting to the "search" functionality of the portal.
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.
hmm, but IF ./exhibition WAS /some/odd/place/on/the/community/site/exhibition/current then i do not see any problem: it is still "close" (and "official") while at the same time it is in the place where it should be....
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.
oh i totally agree. that is why the simplest solution would be to make the "exhibition" tab point directly to the exhibition (without any ./exhibition folder involved). it might not be obvious how to do it (for non-plonistas) but it is really rather simple (i'll not go into the details here)
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,
so what is then going to happen in the /bi/ba/bo/exhibition/? that is a totally empty space (apart from 1 or 2 templates).
i deliberately split the respone email into several parts and therefore stop here.
gfmas.dr IOhannes
On 11/04/2007, at 16.20, IOhannes m zmoelnig wrote:
Steffen wrote:
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.
i have seen so many sites becoming only partially maintained because the workflow of publishing was too complicated. that's the only reason. and to make it structured...so people can find stuff without resorting to the "search" functionality of the portal.
O.k.
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.
hmm, but IF ./exhibition WAS /some/odd/place/on/the/community/site/exhibition/current then i do not see any problem: it is still "close" (and "official") while at the same time it is in the place where it should be....
I kind of knew you would say that. I kind of fed that argument my self, hence i've not mush to add, other then point to the "psychology" and "why-not" and the "it commonly used place" argument. The fist and last is of cause strongest.
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.
oh i totally agree. that is why the simplest solution would be to make the "exhibition" tab point directly to the exhibition (without any ./exhibition folder involved). it might not be obvious how to do it (for non-plonistas) but it is really rather simple (i'll not go into the details here)
O.k. I don't understand it. So I'm interested in how?
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,
so what is then going to happen in the /bi/ba/bo/exhibition/? that is a totally empty space (apart from 1 or 2 templates).
Yes. A template, a schedule and some documentation.
Which completely fills the space. Fullness as an argument in this is orthogonal to the "right place" argument. But, fair enough, is consistent with the "practical" argument.
Steffen wrote:
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
hmm, just because the "files" folder does not appear on the navigation-tree, does not mean it cannot be found. the first hit when searching "vol-0" (ok, who is going to do this?) gives me ./exhibition/files/vol-0
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.
again: just because something is not obivous does not mean it is not visible. webcrawlers tend to find everything, and google caches a lot.
mfga.sdr IOhannes
On 11/04/2007, at 16.28, IOhannes m zmoelnig wrote:
again: just because something is not obivous does not mean it is not visible.
Right. I shall distinguish between those two states/terms. My bad.
This begs for (and makes most sense with) the three states "private", "published", "visible for members only" as defined in an earlier email from you.
It is also similar to the states in the schedule, so it might not complexify the workflow too much.
Steffen wrote:
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."
well, both ways would require interaction from a person who knows a bit plone. the "simple" way requires to add WikiPages to the objects that can be selected as "default view" (currently they are not; this is why you cannot add them); it is not a big deal
the "harder" way requires the installation of a "product" (aka "external") which itself is totally simple; however on the long run, i think it is better to keep the number of external dependencies as low as possible.
mfg.asdr IOhannes
On 11/04/2007, at 16.32, IOhannes m zmoelnig wrote:
Steffen wrote:
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."
well, both ways would require interaction from a person who knows a bit plone. the "simple" way requires to add WikiPages to the objects that can be selected as "default view" (currently they are not; this is why you cannot add them); it is not a big deal
the "harder" way requires the installation of a "product" (aka "external") which itself is totally simple; however on the long run, i think it is better to keep the number of external dependencies as low as possible.
I understand. The obvius question is then: Can I preform the simple way; add WikiPages to be selectable as "default view"? I haven't found it, that is.
Steffen wrote:
On 11/04/2007, at 16.32, IOhannes m zmoelnig wrote:
I understand. The obvius question is then: Can I preform the simple way; add WikiPages to be selectable as "default view"? I haven't found it, that is.
it means adding "Wiki Page"s to the selectable object types in the ZMI. i have done this now, so you can now add them via the default view.
fmgas.dr IOhannes
On 11/04/2007, at 17.53, IOhannes m zmoelnig wrote:
Steffen wrote:
On 11/04/2007, at 16.32, IOhannes m zmoelnig wrote:
I understand. The obvius question is then: Can I preform the simple way; add WikiPages to be selectable as "default view"? I haven't found it, that is.
it means adding "Wiki Page"s to the selectable object types in the ZMI. i have done this now, so you can now add them via the default view.
Thanks a bunch. nice to see it doable. It's still magic to me, but thats all right.
Steffen wrote:
Thanks a bunch. nice to see it doable. It's still magic to me, but thats all right.
so you really want to know how to do it, eh? have a look at: http://plone.org/documentation/faq/add-default-page-types
mfga.sdr IOhannes
On 12/04/2007, at 9.08, IOhannes m zmoelnig wrote:
Steffen wrote:
Thanks a bunch. nice to see it doable. It's still magic to me, but thats all right.
so you really want to know how to do it, eh? have a look at: http://plone.org/documentation/faq/add-default-page-types
O.k. I finally understand that it is out of user-space.
Steffen wrote:
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?
well it is totally possible to open up normal documents to be editable by everybody (or members only). but i do not oppose to putting the docs and orga stuff into WikiPages.
it is only that i feel that there is no necessity for the exhibitions to be Wiki.
fmgas.dr IOhanens
On 11/04/2007, at 16.35, IOhannes m zmoelnig wrote:
Steffen wrote:
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?
well it is totally possible to open up normal documents to be editable by everybody (or members only).
I see. Does that complicate the project work-flow? The schedule for one is to be editable for all members of the site such that every one can add them self.
but i do not oppose to putting the docs and orga stuff into WikiPages.
I know, but to make the docs+orga stuff "visible for members only", they are to be non-WikiPages, if I understand what you wrote above right.
it is only that i feel that there is no necessity for the exhibitions to be Wiki.
You are totally right. They need not be WikiPages. They just need to be something plone'ish such that they can be displayed though the site. It's just that thought that was how things worked (suspect for the system thinking, bummer).
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@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
On 11/04/2007, at 16.40, Hans-Christoph Steiner wrote:
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.
No worries. I'll not loose interest by this. Also i think IOhannes does it for the best. And if he was annoyed by either the project or me he wouldn't spent this kind of time on it.
I'll proceed with the TODO, also.
Best, Steffen
Steffen wrote:
On 11/04/2007, at 16.40, Hans-Christoph Steiner wrote:
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.
right it is getting a bit dense.
No worries. I'll not loose interest by this. Also i think IOhannes
this is good and as i expected it ;-) thanks for your patience
does it for the best. And if he was annoyed by either the project or me he wouldn't spent this kind of time on it.
correct.
i am not talking about "how things have to be" (in a dogmatic sense), but i am trying to add my 2⬠to make the thing even better than it already is.
mfga.sdr IOhannes
On 11/04/2007, at 17.56, IOhannes m zmoelnig wrote:
Steffen wrote:
On 11/04/2007, at 16.40, Hans-Christoph Steiner wrote:
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.
right it is getting a bit dense.
I think the denseness is done now :-)
No worries. I'll not loose interest by this. Also i think IOhannes
this is good and as i expected it ;-)
Great!
thanks for your patience
Well thank you!
does it for the best. And if he was annoyed by either the project or me he wouldn't spent this kind of time on it.
correct.
i am not talking about "how things have to be" (in a dogmatic sense), but i am trying to add my 2€ to make the thing even better than it already is.
That's nobel. I like that.
mfga.sdr
___ /mvh .. (I think i finally got that signature)
steffen
Steffen wrote:
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?
hmm, how about this:
./community/projects/exhibition/ |-- *about |-- submission | |-- .organizing/ | |-- * | |-- schedule | |-- template | |-- vol-1/ | |-- * | |-- files,... | |-- vol-2/ |-- .... |-- .vol-N/
./exhbition --> links directly to ./comm/proj/exh/vol-2 (current)
this has following goodies: - organising the exhibitions in folders (vol-#/) rather than pages (vol-#) plus folders (.files/vol-#) makes each exhibition self contained. - ./comm/proj/exh/ is automatically the archive for all (past) exhibitions - ./exhibition/ is CLOSE to the portal root; going into the ./exhibition/ gets you directly to the current exhition; the "archive" is visible in the side-menu
does this make sense?
fma.dsr IOhannes
On 11/04/2007, at 17.45, IOhannes m zmoelnig wrote:
Steffen wrote:
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?
hmm, how about this:
./community/projects/exhibition/ |-- *about |-- submission | |-- .organizing/ | |-- * | |-- schedule | |-- template | |-- vol-1/ | |-- * | |-- files,... | |-- vol-2/ |-- .... |-- .vol-N/
./exhbition --> links directly to ./comm/proj/exh/vol-2 (current)
this has following goodies:
- organising the exhibitions in folders (vol-#/) rather than pages
(vol-#) plus folders (.files/vol-#) makes each exhibition self contained.
- ./comm/proj/exh/ is automatically the archive for all (past)
exhibitions
- ./exhibition/ is CLOSE to the portal root; going into the
./exhibition/ gets you directly to the current exhition; the "archive" is visible in the side-menu
does this make sense?
It does. I suspect that the bare * is equivalent to *FrontPage.
I like the goodies too, so i think it should be tried out.
There is also a less positive goodie, namely that, if it flops and there is only, say, one or two exhibitions made, then the link from the link from 'close to the portal root' can be deleted without touching the exhibition at all. The exhibition can then continue it's silent life in sleep till waken again without casting shame to the portal. I of cause don't hope that to happen. And it might even be that only few exhibitions deserves the attention. But a "plan b" is then sought for.
mvh steffen
On 11/04/2007, at 17.45, IOhannes m zmoelnig wrote:
does this make sense?
As said earlier it does.
But i'm concerned about the state 'public draft' though. That is, to make it into 'visible for (logged in) members only'. The reason it seam used "incorrect" quite a number of places on the site, which means that making that move might cause trouble?
The only solution to that, i can think of, is to hide stuff from the menu making it not obviously visible but still accessible.
Steffen wrote:
On 11/04/2007, at 17.45, IOhannes m zmoelnig wrote:
does this make sense?
As said earlier it does.
But i'm concerned about the state 'public draft' though. That is, to make it into 'visible for (logged in) members only'. The reason it seam used "incorrect" quite a number of places on the site, which means that making that move might cause trouble?
ok.
you are right that the portal is currently not in the state for this, mostly because all newly created content is automatically in state "public draft" and automatically visible for everybody.
with your consenus i'd like to: - change all content currently in state "public draft" to be "published" - change the default state to "published" (so new content is automatically visible for anybody) - make the "public drafts" to be viewable by members only (and probably rename it to "members only")
is that ok?
The only solution to that, i can think of, is to hide stuff from the menu making it not obviously visible but still accessible.
as said before, i don't like the idea of making content unavailable by moving it out of sight not very much (security by obfuscation that is)
mfa.sdr IOhannes
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
IOhannes m zmoelnig wrote:
Steffen wrote:
On 11/04/2007, at 17.45, IOhannes m zmoelnig wrote:
does this make sense?
As said earlier it does.
But i'm concerned about the state 'public draft' though. That is, to make it into 'visible for (logged in) members only'. The reason it seam used "incorrect" quite a number of places on the site, which means that making that move might cause trouble?
ok.
you are right that the portal is currently not in the state for this, mostly because all newly created content is automatically in state "public draft" and automatically visible for everybody.
with your consenus i'd like to:
- change all content currently in state "public draft" to be "published"
- change the default state to "published" (so new content is
automatically visible for anybody)
- make the "public drafts" to be viewable by members only (and probably
rename it to "members only")
is that ok?
just to add: it is not a very big deal to change all the content from "public draft" to "published". people used "public drafts" because they were not aware that they could change it in the first place (i suspect); and it was visible for everybody, so they just left it in this state.
additionally, i believe, that there is no point in using an elaborated workflow like moderators, who can "publish" stuff that is in state "pending" (a transitional state between "public draft/visible" and "published").
all in all i'd say: 3 states are ok: - published (everyone can see) - visible (only members can see) - private (only owner can see)
the default state should be "published"
the owner of an object should be able to change between states (without the need for a moderator); administrators are able to change the states too; probably another group ("moderators") could be made able to change the state too, but i think this would be an overkill.
people should be able to edit stuff even if it is already published (i think this currently does not work as expected; you would have to make the object "visible" before being able to edit it; this is ok for complicated companies where someone has to censor all the content, i don't think it is needed on the pd-portal)
if all of the above was true, then i think nobody would really notice the difference (apart from the fact, that more links would be blue instead of green...), so no harm would be done.
mfg.adsr. IOhannes
On 04/05/2007, at 12.13, IOhannes m zmoelnig wrote:
if all of the above was true, then i think nobody would really notice the difference (apart from the fact, that more links would be blue instead of green...), so no harm would be done
I think you are right. And i think it is true. And I hope it's not a hassle to change all the content from "public draft" to "published".
Thanks for doing it.
Best, Steffen
On May 4, 2007, at 6:13 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Steffen wrote:
On 11/04/2007, at 17.45, IOhannes m zmoelnig wrote:
does this make sense?
As said earlier it does.
But i'm concerned about the state 'public draft' though. That is, to make it into 'visible for (logged in) members only'. The reason it seam used "incorrect" quite a number of places on the site, which means that making that move might cause trouble?
ok.
you are right that the portal is currently not in the state for this, mostly because all newly created content is automatically in state "public draft" and automatically visible for everybody.
with your consenus i'd like to:
- change all content currently in state "public draft" to be
"published"
- change the default state to "published" (so new content is
automatically visible for anybody)
- make the "public drafts" to be viewable by members only (and
probably rename it to "members only")
is that ok?
just to add: it is not a very big deal to change all the content from "public draft" to "published". people used "public drafts" because they were not aware that they could change it in the first place (i suspect); and it was visible for everybody, so they just left it in this state.
additionally, i believe, that there is no point in using an elaborated workflow like moderators, who can "publish" stuff that is in state "pending" (a transitional state between "public draft/visible" and "published").
all in all i'd say: 3 states are ok:
- published (everyone can see)
- visible (only members can see)
- private (only owner can see)
the default state should be "published"
the owner of an object should be able to change between states (without the need for a moderator); administrators are able to change the states too; probably another group ("moderators") could be made able to change the state too, but i think this would be an overkill.
people should be able to edit stuff even if it is already published (i think this currently does not work as expected; you would have to make the object "visible" before being able to edit it; this is ok for complicated companies where someone has to censor all the content, i don't think it is needed on the pd-portal)
if all of the above was true, then i think nobody would really notice the difference (apart from the fact, that more links would be blue instead of green...), so no harm would be done.
Personally, I think it should be wiki like, meaning only one "state": published. For something that is a work in progress, it can just be called something else, then renamed to the final name. I think that would be the easiest way to setup the way most people use the site.
That's my two bits...
.hc
mfg.adsr. IOhannes
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
Personally, I think it should be wiki like, meaning only one "state": published. For something that is a work in progress, it can just be called something else, then renamed to the final name. I think that would be the easiest way to setup the way most people use the site.
i think both can live happily together.
if someone prefers to rename stuff to and fro, let them do it. if somebody wants to hide things because they are not ready to be published, they can use the states.
anyhow, i have updated the site, so that the default state is "published" and adapted the other states.
if you don't want to use states, you can safely ignore them.
mfg.asdr IOhannes
On 07/05/2007, at 13.15, IOhannes m zmoelnig wrote:
if you don't want to use states, you can safely ignore them.
As it is, or as i understand how it is, it is chosen when creating a page. If one create a wiki-page, then it's a wiki which don't have the different states. If one create a page-page-thing, then it is not a wiki and have the three states. As such i think it makes sense.
Steffen wrote:
On 07/05/2007, at 13.15, IOhannes m zmoelnig wrote:
if you don't want to use states, you can safely ignore them.
As it is, or as i understand how it is, it is chosen when creating a page. If one create a wiki-page, then it's a wiki which don't have the different states. If one create a page-page-thing, then it is not a wiki and have the three states. As such i think it makes sense.
you are right; i should have said: if you use wiki-pages than you don't have to bother about states (they have none) if you don't use wiki-pages and you still don't want to use states, you can safely ignore them. :-)
mfg.asdr IOhannes
On Apr 10, 2007, at 11:53 AM, Steffen wrote:
On 05/04/2007, at 5.55, Hans-Christoph Steiner wrote:
Yay, progress!
More progress.
As put in the proposal "internal" stuff is located '/community/ projects/exhibition' where as the "public" stuff lives in '/ exhibition'.
I've edited the Organizing wiki page <http://puredata.info/ community/projects/exhibition/Organizing/>. If there are errors or unclearness, please correct it or let me know about it.
This looks quite good so far. Perhaps the schedule should be its own page, for the sake of clarity.
TODO:
- Next up is to make a "test" exhibition. This is both to make the
Template wiki as well as to test that "public part" works as it should.
Good idea. Perhaps there could also be an example template to show off some of the formatting possibilities.
- After that i'll try to pitch Exhibition on the pd-list to make
more people aware of it. Hopefully make some folks interested in being curators. In that sales pitch i'll include some possible exhibition themes to ease things up.
Sounds good.
- Mean while i'll update the ToBeFrontPage <http://puredata.info/
exhibition/ToBeFrontPage> till it's nice (what ever that means), and the rename it FrontPage such that it will be the actual frontpage - ie the wiki page that the browser is directed to when pointed to the /exhibition folder. I curently can not manually point it to other wiki pages, hence not manually point it to a to- be-current-exhibition. This might involve wee changes to the dir layout in the '/exhibition' folder. If so I'll of cause let y'all know though here as well as edit the "What's Where" section of the Organizing wiki <http://puredata.info/community/projects/exhibition/ Organizing#ww>.
Sounds good.
- Then it's go-go. People can add them self to take curator slots.
And we see how it all goes.
Thanks for reading.
Glad to see you are cranking on this, seems like we'll have en exhibition soon enough!
.hc
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On 10/04/2007, at 17.53, Steffen wrote:
TODO:
- Next up is to make a "test" exhibition. This is both to make the
Template wiki as well as to test that "public part" works as it should.
I've made a quick dirty test: http://puredata.info/community/projects/ exhibition/vol-0
and a template to go with it: http://puredata.info/community/projects/ exhibition/organizing/template
and also added a brainstorm wiki-page: http://puredata.info/community/ projects/exhibition/organizing/Brainstorm
TODO: - merge the change to org into the wiki - add formating tips to the org wiki - rewrite the about page? - pitch the project -
-
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Steffen