I find the tags very useful as in some cases works better than word search, especially if one remembers only the topic or wants to see items in the topic; sometimes one has no viable alternative. I tag most of my posts, but I understand that some do not, what makes one of the search methods less useful. Maybe, if one does not want to have the site tag cloud on the left of the page, maybe one can add some user switch, css or whatever to hide it for them. In early nLab days I remember to find it superfluous and distracting.
]]>Re #57
it would be good if things still work well if the user does not have javascript enable
It's never been possible to make any edits without Javascript (and cookies) enabled. It would be nice to change that, but for now, I wouldn't want to delay adding an editing feature because it also relies on Javascript.
]]>I never use tags either, but if one clicks on something in the tag cloud, it seems to work quite nicely; maybe it would be worth keeping, in case it one day proves useful? In which case Urs’ idea to link the announcer mechanism up with it sounds good.
Regarding blog functionality, I think possibly this may cause posts to appear under ’Notices’ (although I could be wrong; the things there seem to be completely random and in many cases unintentional). I agree that it doesn’t seem like something we need; I can remove it if others concur.
]]>Speaking of not using nForum features: We don’t use the “blog” functionality. In fact I don’t even know what it is or does. Maybe it could just be removed from the interface.
]]>I never use the tags.
]]>a thought:
When one hits “start a new discussion” here on the nForum, one is asked, among other things, to provide “tags” for the discussion topics. These then go into the “Site tag cloud” that is found on the left of the nForum page.
Now that the new announcement mechanism also creates new nForum threads, should it and could it reflect this functionality?
I am not sure if many contributors here ever got into the habit of providing tags (Zoran does, I think, who else?), and less sure still if anyone ever found the resulting “tag cloud” to be of any use. But on general grounds the idea seems to make sense, and from some point on in the past I got into the habit of providing tags.
]]>Excellent, Richard, so sensible solution ! Thanks!!
]]>Okay, if I’m the only one who is worried, let’s just try it, maybe it won’t be a problem.
]]>In this case, if I understand correctly (I have not checked the code yet) Instiki saves the three edits as three individual, separate revisions. If person B had not made an edit, Instiki would fuse the two edits of person A into one.
Yes!
In the case of announcing to the nForum, we can mirror this:
I’d be fine with this. But didn’t others suggest that this might not be optimal? In any case I suppose we can agree that even if not optimal yet, it would be an improvement.
Speaking of non-optimal: Did you say it might be easy to make the caching of large pages work again? (I seem to recall that presently it doesn’t work simply because the caching agent times out before it receives the page to be cached.) I would find that a big relief…
]]>I contrived to forget that I had commented out something when testing the addition to the user association algorithm described in #62, so that the announcer was not working correctly for a few hours between around #62 and my comment here. I hope that no non-trivial announcements got lost in this time; I am very sorry if so.
One day I hope to set up a proper testing framework for making changes, which will in particular prevent these kind of oversights from making their way into the live nLab, but it is unlikely to be something I have time for in the short term unfortunately.
]]>I’m a little bit confused by the discussion concerning the ’preview’ functionality for editing. Let me try to summarise to see I have understood correctly.
Suppose person A makes an edit, chooses to delay announcement for 30 minutes, and submits. Suppose person B, after this submission and before the 30 minute interval, makes an edit and chooses to announce it immediately, and submits. Suppose person A, after this submission but within the 30 minute interval, goes back and makes a further edit. In this case, if I understand correctly (I have not checked the code yet) Instiki saves the three edits as three individual, separate revisions. If person B had not made an edit, Instiki would fuse the two edits of person A into one.
In the case of announcing to the nForum, we can mirror this: when person B submits their edit, we post both the announcement of the first edit of person A and the announcement of the edit of person B to the nForum, even though person A chose to delay. If Person A on their second edit chooses to announce in the nForum, it is now done as a new announcement. Of course they can manually edit their first announcement instead if they wish. We can add a message to the edit page indicating to Person A that their delayed message has in fact been posted, link to it, and say that they can edit it manually if they wish rather than post a new announcement.
With this design, I don’t see any problem with Zoran’s suggestion of putting the announcement text in the edit page if person A comes back within 30 minutes and their message has not already been announced. Indeed, this seems like a good idea to me: they might wish to edit their announcement according to the new changes, or might suddenly have a wish to change the announcement text itself. I don’t think we need any instructions additional to those we have now to explain this behaviour, beyond including an indication if the announcement has already been posted due to somebody else’s edit. Perhaps I’m missing something?
]]>Several people (David C, Todd, Tim, Oscar, …) have a user name which is formed by combining a first name and surname with an underscore, so I have now added a check for this to the user association algorithm.
]]>I think the edit clashes are handled by locking system well at present – the lock is there when somebody is actually editing, not between two saves of longer editing process. I this this is fine – it is nice that as long as I stop editing somebody else can edit as well without delay, and this is good when we discuss the issue online. Mike’s issue is that one often changes the mind minutes after the fact (even if one intended to leave the page as final edit for today), say after realizing some fact or rereading some source or related pages, and for edits that was never a problem as the historical page even if recorded as a version due somebody’s else’s edit, is not presented in front of our eyes, but only in the history of the page. This is a bit different with the announcement to the Forum as it stays there. Though we more rarely change our text in Forum, the author can adapt the announcement there manually (Richard said this is possible as it is associated to the author at both places). So, I think there is no major reason to further rigidify our present lock system and slow down the sequences of collaborative edits this way.
]]>An easy solution would be if one could simply lock an entry for a while independently of how “edit” and “submit” are hit.
That would effectively provide a “preview” functionality and prevent edit clashes, even besides the issue of announcemnts.
]]>the same editor should have his previous announce commentary available in the box when editing… the delay announcement should be finalized by the system if another person edits the page
I thought of that too. But then I didn’t suggest it, because I didn’t like the situation where I make an edit with a comment, expecting to be able to come back and modify my comment after seeing the save “preview”, but then someone else unwittingly sneaks in an edit first and my comment gets unexpectedly finalized. Of course, that’s what I should expect might happen, but I think the instructions “If you re-edit the page within 30 minutes before someone else does, you will be able to modify your comment, but if someone else edits the page in the meantime your comment will be posted to the nForum as-is” are too complicated.
]]>47 I suggested the same in another thread. 56: If post with delay is to be implemented in the sense of 47 that would mean that the same editor should have his previous announce commentary available in the box when editing. I mean, when we edit then our name automatically appears in the bottom. I am not sure how this is implemented, from the host side or from the client side. If it is from the host side, than it is probably easy to ass to add the text of the draft comment to appear in the announce box.
Now what happens if a new person edits before the delay period happens ? As for the usual edits, usually the new version is created with a new editor. So, the delay announcement should be finalized by the system if another person edits the page (this in particular assumes that the page is not locked, of course). This is the only logical behaviour as far as I understand.
]]>Sounds good! I like this approach, where all options are available in the user interface from the beginning. With it, though, there is the question of how to handle the case that the user clicks more than one box. I don’t mind adding some client side code for this (which can either prevent clicking more than one box, or do a check that only one is checked when one clicks submit), but it would be good if things still work well if the user does not have javascript enable. We could just have some default prioritisation in such a case, but it would be nice if there were some better solution.
]]>How about changing the “Indicate your changes” checkbox to a three-option radio button set: Don’t post, Post immediately, Post with delay.
]]>A slight tightening up of the page creation text
Thanks! Have now changed things so that your text is used (up to a couple of very minor tweaks).
Let’s not confuse the user with too much choice; I think it would be simpler and sufficient to just always use the same timeout.
I agree that simplicity in the user interface is very good. Let’s forget about the user being able to choose the delay, then; but I think that we should keep the choice to announce immediately or delay though, as I can certainly imagine circumstances where one would wish to announce immediately.
If anyone has an idea of a nice user interface design which would allow me to implement this choice between announcing immediately or delaying without needing client side code, I would be very happy to hear it! (The wish to avoid client side code is not due to any difficulties with implementing such a solution, it is more of an aesthetic/infrastructual one.)
]]>Let’s not confuse the user with too much choice; I think it would be simpler and sufficient to just always use the same timeout.
A slight tightening up of the page creation text:
]]>Please make some comments about this new page, such as a brief summary of its contents, how it relates to other extant or potential pages, and how it might be further developed. They will form the first comment of a thread at the nForum for discussing this page.
Re #44; you’re welcome!
Re #46-49: I can indeed implement a delay when I get the chance. It will need a little work, probably a new table in the database. Instiki’s delay is 30 minutes, and resets if a new edit is made in that period. I was thinking to allow the user to choose whether or not to announce at once or delay, maybe with say a dropdown list with some reasonable time periods, and maybe a textbox where they can either manually enter a period of time, or maybe a timestamp at which to announce.
Re #33: as announced here, I have now made an initial implementation of another of Mike’s ideas, namely to have a link on each nLab page to its corresponding nForum discussion. Let’s maybe use the other thread to discuss that functionality, as it is separate in its implementation from the announcer functionality.
Re #45: thanks very much for the improved wording! I have now used it (up to some extremely minor tweaks) to replace what was before.
Below is the current text for page creation. Let me know if you have a suggestion for an improvement of it too.
]]>Please make some comments on the page you have created below. They will form the first comment of a thread at the nForum which will be made to discuss this page. Typical comments include your motivation for creating the page, how the page relates to existing nLab pages, your plans for the page or for further edits or page creations elsewhere in the nLab, or how the page can be further developed.
By the way, Urs, I think you made a comment earlier, which I believe you have now edited out, that you had a problem with uploading pdfs. Did you get it working in the end?
]]>Re #50: My apologies, I had introduced a bug yesterday when fixing a different one! It should be working now. Testing page creation is a little tedious as I have to do a bit of cleaning up afterwards, so I’m doing it less often, which is why we’re seeing some bugs with creation and not so much with editing. Would you like me to fish out your announcements from the logs?
]]>it seems that the automatic announcement for newly created entries does not work anymore. I have created brief category:people entries for hyperlinking of references (John Brodie, Marco Fazzi) but the announcements did not appear here.
]]>