edev

Edevdocs are a problem.

Firstly, I've seen a lot of edevdocs around that seem to indicate that people aren't aware of the difference between edevdoc's and superdocs. So, you know, maybe we need a bit of documentation. Hey, it's just a thought.

Secondly... brackets. Brackets are, of course, a pain on Everythings in general, what with parselinks being used somewhat universally on content.

There is no simple, elegant way to denote a bracket that will survive a trip through parselinks. The standard way of passing a bracket through parselinks doesn't pass a bracket through at all; it just passes the HTML entity for a bracket, [. This only happens to look a bit like a bracket when your browser renders HTML. As far as, say, JavaScript is concerned, though, it's not a bracket at all.

The 'solution' we currently have in place to this problem, is, in a word, wrong. The solution is that while normal documents are displayed with parselinks, edevdocs are displayed with devparselinks, an entirely different function.

This brings trouble when we have a javascript utility, such as E2 Bookmarklets or Writeup table formatting utility which we want to open up to the general E2 user population rather than just edev, the only real way to do this is to convert the edevdoc (viewable only by edev members) into a document, viewable by all. And here we can get bitten by the difference between documents and edevdocs.

E2 Bookmarklets uses its own scheme to get round the lack of brackets; if it had used the edevdoc scheme, it would be useless in a document.

There are ways to get round the lack of brackets, of course.

• construct any regular expressions using ASCII equivalents, and for array dereferencing, parselinks can be defeated by using, eg:

  array /*[*/ [i /*]*/ ] = f(i);

  This causes the HTML generated by parselinks to be encapsulated inside the javascript comment, while the following [ is thought to be inside the '[]' so isn't interpolated, and the closing ']' is thought to be an unmatched ']' so isn't interpolated.

  Please note, the technical term for this method is 'A Gross Hack', and if I find anyone attempting it, I shall kill them. Or... you know, laugh at them. Whichever I feel like at the time.

• encode the code (eg. with escape) and store in in a string, which can then be unescaped and evaluated. The edev JavaScript escaper will do this for you.

However, I would like to propose that we actually solve this problem, rather than simply bubble-pushing it. I see two solutions:

1. Create a publically accessible nodetype that uses devparselinks for its display page, which edevdocs can be transformed into to make them publically accessible. Naturally, for the same reasons that edevdocs can only be viewed by edev members, we would want to ensure that the new nodetype can't be created by non-deity edev members, but can easily be created from an edev member's edevdoc. Alternatively,..

2. Beef up parselinks so that it doesn't catch brackets which are inside HTML tags or HTML comments (a little tricky perhaps), so it ignores brackets inside properly commented-out scripts. Such a parseLinks might look a little like this:

       my ($field) = @_;
       my ($text) = $$NODE{$field};
       join "-->", map {
           my @a = split /<!--/, $_;
           $a[0] =~ s/\[(.*?)\]/linkNodeTitle ($1, $NODE)/egs;
           join '<!--', @a;
       } split /-->/, $text;
   

   Not quite as elegant as the current definition, but certainly does the job.

You may remember that, several months ago, we (edev) had a discussion regarding collapsible nodelets. A collapsible nodelet is a regular nodelet with a button that allows you to hide or display the nodelet contents. See a working example here. Collapsible nodelets would allow quick access to the nodelets you want, while keep your screen somewhat clean by giving you the ability to quickly hide or show the ones you refer to semi-frequently (without needing to go through User Settings).

If I recall correctly, most everyone liked the idea of collapsible nodelets, but there seemed to be no way to store info regarding which nodelets are collapsed without posting back to the server (not very fast at all). Since no solution appeared to this problem, the idea was pretty much abandoned. Today, however, it suddenly struck me to (duh!) use JavaScript to store data in cookies regarding which nodelets should be collapsed and which should not. I've got a working example running here.

Okay, this suggestion has been implemented and tested well enough to be fit for general consumption. I'm quite happy with the multi-room chat and view client available at squawkbox. It might have a new name sometime in the future and if this is the case, I'll update the link. This takes the purpose and considerations of m_turner's proposal, but changes a few things that I think make it a better tool for the job.

The chatterbox nodelet is simple, only addresses one "current" room, etc. Its main strength is how little it takes up in screen real estate. It works on the right-hand side and stays constrained and keeps page layouts working well. I'm not generally a fan of adding additional nodelets for a few reasons: performance, ease of use, positioning, etc. People tend to add nodelets and forget about them, adding needless additional calculations onto their page. It's not very easy to add them, nor move them around. Yes, this is an addressable shortcoming of the site, but it's low priority.

I'm not generally fond of having a separate control element from the chatter element. It's not blatantly obvious to add another nodelet to change your chatter prefs realtime, and I'd like for it to be fairly dynamic (one or two clicks to change everything). The nodelet adding and moving mechanisms are kind of crappy right now (and that's one of the things keeping us from splitting out private messages and chatter, other than tradition), so your control mechanism can end up at a different end of your page than your display mechanism.

My only other concern with the proposal as it stands is that the chatterbox nodelet might be too wide with the room name in it. I'd like for you be able to multi-browse all of the rooms, despite which ones we declare as "special". To accomodate this, some of them have some fairly long times. We could substr() the string and tack on a (...) if we really need to, but we'd need to cut the name fairly close to get it to fit on screen with a message. It's an obvious feature request that'd come up anyway, despite the current lack of popularity in the room feature..

I've taken the interface suggestions and replicated a little bit of chatterbox functionality inside of the squawkbox. We still use the message opcode, so it is as compatible as possible. We fake out a lot of the functionality, so it looks clean and doesn't require a lot of deep hacks to get it to work. It's tabled to keep the information as clean and in line as possible. If you are currently talking in a room, the room name will be bolded, and the topic shown. You can change the room you're talking in, delete an arbitrary amount of rooms, and chat all in the same action.

I might be interested in moving this to the small-screen (AKA the nodelets), but currently we have size considerations that squawkbox (as a superdoc) has the luxury of avoiding. I'm happy with it as is, but if people have additional improvements to layout and interface, please let me know. I'd also like to investigate this as a possible chatterlight replacement. We'd need to layout both this and showmessages in what turns out to be limited screen space for some of our users. We'll have to see. Comments and suggestions by private message, or longer than two messages to jaybonci@everything2.com.

The chatterbox is a great thing. Some of you may agree with this - some may not. However, it is part of how E2 is now. People need to talk, and communicate and not everyone can (or wants to) get on to IRC to do this.

The biggest 'problem' with the chatterbox is the topics / rooms. Typically a conversation will eventually spill inside to the outside room. Given the current climate of the world, a war or government debate will take place. This either gets borged, pushed into the political asylum or takes over the conversation and people get pissed. This is not a good thing.

The ideal solution is to have the chatterbox allow a person to watch multiple rooms at the same time so they don't feel 'left out' of outside head back there, and eventual start talking about something that is best discussed in another room.

The biggest problem with this is the interface short of switching back and forth between the rooms you want to watch constantly, there is no good way to do this.

First off - the how it looks.

If you ware watching one room and only one room, then nothing in the way things look changes. This is good. If you are watching two or more rooms then the rooms that you are watching but not 'in' (you can still only be 'in' one room) would have the name of the room prefixed to the chat message :

---

<m_turner> Boobies!
(political asylum) <g.w.bush> War!
(noders nursery) <newbie> votes?

Room messages will be sorted by room and then by date. It may be reasonable to put a <hr> tag between room sections. Further improvements to the interface could be done akin to EKW theme changes - allowing the talk room to be one set of font attributes (size, font, color) and the watched rooms to be another set of font attributes.

Second off - how to control it

Control over the multiple rooms would be given in a room control nodelet:

watch  room               talk
 _X_   outside            (o)
 _X_   political asylum   (_)
 ___   noders nursery     (_)
 ___   ______________     (_)

The watch box is a checkbox.
The talk spot is a radio button.
The _______ is a text field.

One non-standard room is allowed for fill in. This is automatically set when a noder visits to a non-standard room node. In theory more than one non-standard room could be allowed - though it may get confusing.

Selecting a spot room with the radio button automatically checks the watch box for that room (upon submission - javascript not needed). talking in a room implies that you are watching it too. You cannot talk in a room you are not watching.

The effect of this should be good for E2 - it allows a person to not feel left out about a topic in one of the other major rooms while still discussing matters within a particular room. Editors and mentors can talk to people in the nursery without being lost from the view of everyone else.