Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
Just to let you know that I am currently implementing and testing the ideas discussed here and in a few of the following comments. If you see some posts with author ’nLab edit announcer’, they have been generated manually by me.
Edit made to nLab edit announcer by Richard Williamson at 2018-03-26 17:33:16 UTC.
Author comments:
Test.
Seeing if this works.
Edit: nLab edit announcer by Richard Williamson at 2018-03-27 08:48:42 UTC.
Author comments:
Test.
Seeing if this works.
Neat, thanks for working on this! It would be nice if the forum post author could appear to be the person who actually made the edit, but maybe that’s not feasible.
Edit to: nLab edit announcer by Richard Williamson at 2018-03-27 18:47:30 UTC.
Author comments:
Test.
Seeing if this works.
Edit to: nLab edit announcer by Richard Williamson at 2018-03-27 18:50:16 UTC.
Author comments:
Test.
Seeing if this works.
Edit to: nLab edit announcer by Richard Williamson at 2018-03-27 18:50:58 UTC.
Author comments:
Test.
Seeing if this works.
Re #4: Thanks for the suggestion! I can definitely implement this. I’ll get something up and running first, and then can look into it.
On the chance that this is related to changes being implemented: I’m editing an article on my private web, where hitting the edit button produced
XML Parsing Error: not well-formed Location: https://ncatlab.org/toddtrimble2/edit/prime+number+theorem?break_lock=1 Line Number 553, Column 83:
When I hit the back button and tried again, it showed that yours truly was editing the page, and when I hit “Edit anyway”, I got the error message again.
Is there something I can do to break out of this impasse?
Sorry, yes, this is due to work I am doing. I am attempting to minimise disruption. Unfortunately there is no way to test except live.
There should not be a problem just now, but occasional disruption may be experienced until I announce that things are finished here.
No worries at all; I just wanted to make sure it was this and not something else. Thanks for confirming.
More importantly, thank you for all the good work you’re putting into these improvements!
While we’re on the topic, though: I guess that edits made on unpublished webs should not be announced on the nForum, right? (I have one published web, and one unpublished.) I seem to see the announcement box you’re creating showing up in edit mode on my unpublished web.
Good point, yes, I’ll need to implement that.
Actually, I think only edits made to the main nLab web should be automatically announced on the nForum.
Hi Richard,
this is looking good!
Maybe the announcement message could include a pointer directly to the “diff”-version, e.g.
https://ncatlab.org/nlab/show/diff/dark+matter
or, maybe better, a pointer to the diff-version of the corresponding revision page, e.g.
https://ncatlab.org/nlab/revision/diff/dark+matter/15
How about the author name of the announcement message here: Presently it is “nLab edit announcer”, maybe eventually we could include the actual author name?
Anther thought:
Since there is no preview-functionality on the nLab, I got used to making numerous intermediate “Submits” while compiling a non-trivial edit. The Insitki-Software favors this behaviour by counting any two edits to the same entry by the same user within a few minutes (is it 30 minutes?) as a singe edit.
Maybe this should also be reflected in the behaviour of the nLab announcer. Or maybe we need to change our edit behaviour. But then there should be some place where one can develop edits without generating announcements. For instance the Sandbox should probably not generate edit announcements.
Re #16: very good point.
Also I didn’t check to see whether the nLab edit announcement on the nForum allows the author to edit the announcement, but I can imagine instances where one is tempted to say more than there appears room in the box that appears on the edit page. (I haven’t yet tested any of the implicit assumptions I’m making here.)
I think we can now say that the initial implementation is done: it is live for both page creations and page edits, and seems to be working as intended.
I have now hopefully addressed the request in #12 and #14: the announcement functionality should only be present on the main nLab, not on personal webs. For those who have a personal web: please check.
For those interested, the way this has been implemented is that there is a tool (’API’, in the jargon), written in Python, which does the work of posting to the nForum. It is compiled to C and then a binary by means of Cython. This binary is called from Instiki when a page is edited or created.
There will certainly be things that crop up that need improving here, so please continue to come with feedback or bug reports. So far, there are two main requests.
1) Names of authors rather than the generic ’nLab edit announcer’. Requested independently by Mike and Urs. Easy to implement, as it concerns only the Python API. What I plan to do is to check if there is an nForum user with the same name as the nLab author, and use that user if found; otherwise use the generic one.
2) Updated edits rather than new ones in a window, like with the Instiki editing. Requested independently by Zoran and Urs, supported by Todd. This should be fairly easy too, but probably will take me a bit longer, as it concerns the Instiki part, and my Ruby/Rails experience is minimal, though I am gradually picking up a few things, especially after having completed the initial implementation here.
I also foresee some issues with ensuring that the nForum doesn’t get too slow, as the database will likely soon have considerably more entries than it does today. But we can cross this bridge when we come to it.
Re #17: the edit box should be scrollable, so one should be able to write as much as one likes (as long as it fits in an nForum comment), but let me know if I should increase the default size. Once we associate a generated nForum comment with an nForum user, that user should be able to edit the comment in the nForum, yes.
I have by the way fixed, while I was working on the implementation of the new functionality, a bug with the edit box on Chromium in Linux (it was miniscule).
I have attempted now to fix some whitespace issues in the announcer.
Forgot to reply to #15: yes, I can add this, I will add it to the TODO list.
Looking at how this is working out so far, I’m very worried that it will make the forum unusable by filling it up with spam from trivial edits. I thought the idea was that a trivial edit would not be announced at the forum at all?
Thanks for the feedback, it is no problem at all to switch it off completely for trivial edits if people wish for that. Just in case it was not clear, trivial edits appear only in the ’nLab edits’ thread. It’s still early days, it’s only been live for about 12 hours, so let’s maybe wait and see a bit, but certainly I expect to need to tweak things for a while until we end up with something that works well. I’m happy to follow whatever people wish.
Have now switched off announcements for Sandbox, as suggested in #16.
Even keeping the trivial edit announcements in the ’nLab edits’ thread still spams the RSS feed. If we do want them to be announced, maybe we could put them in a different category altogether that wouldn’t get posted to the RSS feed.
I have now implemented the first main request, namely 1) in #18: if it is possible to associate an nForum user to an nLab author, the nForum user is now used to make the announcement rather than the generic ’nLab edit announcer’. The algorithm for associating an nForum user to nLab author is:
1) Look up if there is an nForum user with the same name as the nLab author.
2) Split the nLab author into separate words. If there are exactly two words, tries to match these against the ’first name’ and ’last name’ of a user.
3) Reads a manually created dictionary of author-to-user mappings, looking up whether the author is present.
Re #25: Thanks for this, I have not used the RSS feed, so do not know how things look there. I would expect that it should be possible to tweak the code for the RSS feed to filter out trivial edits if this is desired. But as I say, this is just an initial implementation, I’m happy to tweak it according to people’s wishes, or to remove it completely should the present solution be felt to not be an improvement on the manual announcing that was typical previously.
I do see some advantages in having all edits, even trivial ones, registered in the nForum. I know that one could also look at Recently Revised, but the nForum is more convenient, for me at least. But I’m perfectly happy to implement whatever people wish. So far there have not been many edits since I finished testing, I suppose in a few days’ time we’ll be in a better position to judge which things are working satisfactorily and which are not.
I believe that discussions in “The Cave” already don’t appear in the RSS feed. If true, I don’t know how that’s implemented, but however it’s done it ought to be possible to create another category specially for trivial edits and have them announced there. Personally, I don’t really see a benefit to having trivial edits announced – I would never look at that category myself – but if other people do, I’m perfectly happy to have it as long as it doesn’t drown out the contentful stuff.
Thanks again for doing this work!
I agree with Mike #28: I really don’t want such a barrage of mostly minor edit announcements filling up my inbox.
Something too about the form in which these announcements (trivial or not) are delivered is, to my eyes, pretty monotonous and robotic-looking. I am missing the much more human feel that “Latest Changes” used to have. I was happy to cast my eyes over all of Urs’s posts to the nForum the way things were before, hearing his voice so to speak, but I’m beginning to find the current form actually unpleasant to wade through.
I’m sorry to say so, because I know Richard has been putting in a non-trivial amount of time and energy into this. But maybe let’s step back a minute: I thought all this began with the observation that we want to encourage nLab editors to register their (non-trivial) edits at the nForum. Might it be enough just to have a simple message below the edit box that reminded people to please remember to announce your non-trivial edit at the nForum, and maybe provide a link, rather than have a machine announce it for them?
Which brings me to something else. A lot of people complain about having to register an account in order to use the nForum. I forget – can someone remind me why that’s necessary? After all, isn’t it true that anyone off the street can go in and perform an nLab edit?
FWIW, my nLab edits are under the name ’David Roberts’, but my user name here has no space.
I personally prefer the Wikipedia approach where small comments about an edit are part of the version history.
The nLab’s version history is displayed in Latest Revisions and also for each page its history - e.g. cubical set (history).
These history displays could use some more info
a small comment such as “fixed typo”, “added link to globe”, “added 2 pgh explanation of …”
a character count and count difference from the previous version.
One other problem is in the display of color coded version differences, e.g. cubical set (changes). This usually works well but doesn’t show non displayable changes - aliases, maybe links with changed urls, and what else? Those too should be displayed. Right now the only way to determine those sorts of changes is to feed the sources of two versions into a diff like tool.
No problem, I can switch off the functionality as soon as I get the chance. This will not be before this evening European time, but hopefully I’ll get the chance then.
Something too about the form in which these announcements (trivial or not) are delivered is, to my eyes, pretty monotonous and robotic-looking. I am missing the much more human feel that “Latest Changes” used to have.
Thanks for having the courage to say this; I feel kind of the same way. But could we make the robot sound friendlier? For instance, what if we remove the timestamp (the time of the forum post itself is after all the same as the time of the lab edit) and just insert the user comments? Among other things, that would make it much easier to read through a forum discussion that includes such posts.
The automatically-added link to the lab page is nice, but we could insert that less obtrusively as a parenthetical at the end, so that the forum post would appear something like
Added link to citation by Foo and Bar. (v1465, diff, current)
(I’m also thinking that it might be nice to link not just to the current version of the page, but permalink to the version where the edit was made and the diff. But that’s debatable; it does add a bit of extra noise.)
I agree with Rod that it’s also nice to have small comments be part of the version history, and that it would be nice to be able to display a diff of sources in addition to rendered versions. But I also think it’s nice to have substantial edits posted as part of a discussion that also supports additional conversations about past and future edits to the page, so that they fit into context. Often I have a lot of trouble making sense of a Wikipedia talk page because many of the comments refer to past versions of the page, and even if I felt like taking the time to figure out exactly which, it would be a lot of work matching up their timestamps with those on the edit history. Having edit announcements interspersed in the forum conversation makes that much easier, and would be even easier if the edit announcements included permalinks. For extra super bonus points, the version history displayed on the nLab could also permalink to the forum autoposts corresponding to each nontrivial change!
If the edit author doesn’t match a forum user, we could add their name as a short signature as well (no need to do this if it does match, since their name will be on the post):
Added link to citation by Foo and Bar. – John Q. User (v1465, diff, current)
Another thing that would be very nice to have, especially now that you’ve implemented the ability for the lab to “find” the appropriate Latest Changes forum thread, would be to simply include links to that thread on the edit page, and also on the main page. The link on the main page (like the links to “Talk” from Wikipedia) could say “Forum Discussion” at the bottom alongside “… | See changes | History” — or even at the top alongside “… | Feeds | Export”, to make it more visible, although it wouldn’t really fit contentwise there since the rest of that menu bar is not specific to the current page. The link from the edit page could be in the text that goes along with the “describe your changes” box, and could mention that manually posting your changes is an acceptable alternative to autoposting, especially if you have a lot to say. Something like:
Briefly describe your changes (e.g. “created stub”, “added citations to Foo and Bar”, “wrote a long introduction”, “fixed typo”):
[text box — maybe only a one-line box, or a textarea with only a few lines]
[checkbox, unchecked by default] Automatically post this description to the nForum discussion for this page, signed by your nForum user if it matches the name entered above. This should only be done for nontrivial edits (not typo fixes). Alternatively, feel free to leave this unchecked and instead post manually on the nForum discussion. [link opens in new window]
Finally, I just realized that it makes me somewhat uneasy to have posts on the nForum that are “signed” by me — which I normally have to log in with a username and password to be able to make — being generated by making an edit on the nLab where I enter my name but don’t have to log in with any password. That is, with the current setup any random spammer could make an edit on the nLab and type their name as “Mike Shulman” to generate a forum post that appears to be made by me. We’ve (almost?) never actually had a problem with instiki’s lack of passwords to protect edit-names, so this probably wouldn’t be an issue either, but the idea of breaking a password-boundary in this way makes me uncomfortable. How hard would it be to implement some sort of optional login to protect instiki editnames?
(Separately, I agree with Todd #29 that it would also be nice to allow “guest” posts at the nForum without logging in.)
Again, thanks a lot Richard for taking the time to implement and experiment with new features like this, and for being willing to listen as we all figure out what we want. I know what it’s like being on that end of a “what about this feature? can you do this? hmm, actually I don’t want that after all” conversation. (-:
Sorry for the flood of trivial annoncements yesterday. Still learning how to use the new mechanism. I suppose I should un-check the announcement checkbox for such edits.
Thank you all for the thoughts. Whilst I am happy to remove the new functionality completely, my impression from Mike’s comment and implicitly from Urs’s is that people would like to try out some variations first. So I have for now done the following:
1) Removed all announcement of trivial edits (defined for these purposes to be ones with the checkbox unticked), and removed the thread ’nLab edits’. Trivial edits are still logged on the server. I have also tweaked the instructions to actively discourage announcement of trivial edits.
2) The default is now unchecked, i.e. by default a change is trivial, and the editer must tick the box to make an announcement.
3) I have attempted to follow the suggestion of Mike to make the announcements more ’human’. The comments are now simply posted verbatim. If the nLab author cannot be associated with an nForum user, the name of the nLab author is added at the bottom of the comment. I can add the diff links when I get the chance.
Please give feedback on whether this improves things. As I say, I’m happy to remove it completely if this is preferred.
Re #34: Thanks Urs, this is my fault for not making things clearer. Hopefully the instructions are clearer now, just let me know how to improve them if not. Yes, it would be great if you do not tick the checkbox for trivial edits.
Re #30: Thanks for checking, but the algorithm will manage to associate you correctly, David :-). In the database, there are parameters ’FirstName’ and ’LastName’ for a user in addition to the actual username, and you have David and Roberts as these, so as long as you use ’David Roberts’ on the nLab, the algorithm will find you :-).
Re #29, #31 and #33: thanks for the suggestions! Lots of good ideas here. I don’t know how soon I’ll be able to implement these kind of things, but, as I noted in #35, I’ve made a start.
I do think that there are some advantages to creating an announcement from an nLab page, not leaving it purely manual. For one thing, it is a bit quicker and more convenient than needing to go to the nForum, possibly log in, find the relevant discussion thread, and add to it.
But obviously the announcements need to fit in with the strengths of the nForum, not destroy those strengths, and maybe that will be impossible. Let’s see what people think about the latest approach.
I like the new functionality. I find it very convenient.
One suggestion I have is that we reword
Announce on the nForum
to something that sounds less dramatic and more compelling, such as
briefly indicate your edits
(the way it is for instance for edits on MathOverflow). Because apparently the connotation of “public announcements” created a psychological barrier with at least some contributors here.
right now in trying to display https://ncatlab.org/nlab/latest_revisions (in firefox and chrome) I’m getting an error message. Firefox says
XML Parsing Error: junk after document element
Location: https://ncatlab.org/nlab/latest_revisions
Line Number 4, Column 1:
<p><a href="https://ncatlab.org/nlab/show/HomePage">nLab home page</a></p>^
Re #40: Thanks very much for reporting this, Rod. Now fixed. There were two issues here. One was a bug (null pointer exception) in Instiki’s ruby code which underlies the page one gets upon a 500 error. This is what caused the XML parsing error. I’ve now fixed the code. The other issue was the reason for the 500 error, which was that I deleted a test page I had created in the ’pages’ table of the database without deleting the corresponding entry in the ’revisions’ table. I have now made the appropriate additional deletion.
Re #39: Thanks for the feedback and suggestion! I have now made an attempt to tweak the wording along the lines you suggest. I omitted the ’briefly’ from the checkbox itself, but added it to the instructions above the checkbox. Let me know if you’d like me to tweak it further.
Re #33: I’ve now implemented the linking to the edited/created page and to the diff in more or less exactly the way you suggest, Mike. See also this thread. Feedback and suggestions for improvement welcome.
Sounds awesome! I’ll check it out when I have a chance (am traveling now).
Now that we have tried it out a little, I am very happy with the new announcement mechanism. Thanks, Richard!
Yes, I think it’s good; thanks again!! I have two thoughts after using it. One is that the instructions are rather long; what about a condensed version like this:
For nontrivial edits, please tick the checkbox below and describe the changes briefly; your comments will be added to the nForum discussion thread for this page, which can also be used for further discussion related to this page. For trivial edits, such as correcting typos, please leave the checkbox unticked; feel free to ask for advice at the nForum if you are unsure.
The other is that, for me at least, the auto-announcement mechanism interacts a little uneasily in my head with instiki’s “save is preview” philosophy. With manual announcements, I can edit the page, see how it looks, then go back and fix it to my satisfaction before heading over to the nForum to announce the change. But when using auto-announce, if I tick the box on the first edit, then if it looks wrong I feel a bit rushed in going back to fix it, since it’s already been announced and other people could be looking at it already — whereas if I don’t tick the box on the first edit, then if it looks right on first try I would have to re-edit the page for no reason in order to use the auto-announcer. I’m not sure if there is a solution to that, I just thought I’d share… (-:O
I concur with all of #45, first of all joining the chorus of thanks and saying I’m happier and happier with the results, and second with that slight lingering uneasiness.
A solution would be to have the program wait until 30 minutes (or however long) had passed with no changes before announcing the edits on the nLab. If there had been multiple edits it could combine them and announce them simultaneously.
That’s a good idea, Oscar. Multiple edits from the same author in a short span of time (I’m not sure how short) are already combined by instiki into one entry in the revision history; maybe the auto-announcer could just wait until that span (whatever it is) has expired, and then announce the edit, as it is now in the “final” form that’s not going to change in the revision history.
I like that idea (as in #16)!
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.
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?
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 #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.
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.
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.)
How about changing the “Indicate your changes” checkbox to a three-option radio button set: Don’t post, Post immediately, Post with delay.
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.
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.
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.
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.
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.
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’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?
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.
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…
Okay, if I’m the only one who is worried, let’s just try it, maybe it won’t be a problem.
Excellent, Richard, so sensible solution ! Thanks!!
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.
I never use the tags.
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 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.
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 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.
1 to 73 of 73