Cool trick and tip of the day:

For those of you who fondly remember the days when there was an IBM 3270 terminal on your desk ... run the Citadel client locally on your machine and put "status_line=1" in your .citadelrc

You'll get an adorable status line on the screen that shows the host, room, etc. you're in, along with encryption status and the number of new emails you have. And for that authentic IBM flavor, you'll notice that on the right side there's a little "X" icon that appears when the client has a transaction in progress with the server.

(Yes, on a real 3270 it was a clock, but text-mode 3270 emulators always used an X instead)

Try it on a slow connection for that authentic "I'm waiting for the machinee" effect.

Cool. Thank you. BTW: I was searching for the config file... then I
realized it's called `citadel.rc`

You can copy citadel.rc to a file called ".citadelrc" in your home directory.
When this is found by the client it will be used instead of the global citadel.rc file. This gives you the option to customize it for just yourself and not everyone else on the same computer.

A couple of small changes to the text client are coming soon:

1. No more "localhost" wholist entries.
The text client will be smart enough to show the actual location of the user, even when it's running on the localhost and connects to 127.0.0.1 instead of the local socket.

2. A little experiment where we warn users about using '<E>nter Message' when they should be using '<R>eply'. Initially, this is only going to happen in rooms whose default view is "Blog". Today, a site like Uncensored can't have world-writable Blog rooms because many text client users still habitually use <E>nter when they should use <R>eply, and that creates a top-level Blog post instead of a comment. We'll experiment with this and see where it goes.

(Uncoincidentally, this is the same reason we can't easily do a topics-and-threads view ... but it could be argued that this would be somewhat un-Citadelian anyway.)

I'm not sure when Uncensored will receive the new software. I have to upgrade us to 64-bit Linux, which involves a time consuming database conversion. I might just do it at the same time.

Suggestion - add an option in .<E>nter <C>onfiguration to allow users to bypass warnings - this assumes that the warnings will display initially and the user is basically acknowledging that they prefer to do things the "Citadel way".

Another alternative would be to remove <E>nter message for these rooms and require text client users to .<E>nter <N>ew message or .<E>nter <R>eply. This bears in mind that the intent behind the text client is to keep the workflow of the associated user experience as simple as possible.

Just my $0.02 on something I use exclusively since it is so much easier to work with accessibility tools in order to read and navigate.

Whatever you do, don't make it more inconvenient for regular people to use the client for the sake of making it safer for dumb users :-)

Suggestion - add an option in .<E>nter <C>onfiguration to allow users

to bypass warnings - this assumes that the warnings will display

Well, we do have the "expert mode" setting for that.

The problem is that many of the "experts" have been using Citadel for 30+ years and aren't aware of threading semantics, so they just whack "<E>nter-message" when a "read-<N>ew-messages" operation exits to the room prompt. You (winzlo) did exactly that in the message I am replying to now. This is understandable when you're living inside a user interface that doesn't display the threads.

I've experimented with threaded views, but it doesn't work right when many users are starting new threads every time they hit <E>nter instead of <R>eply, and I can't even blame them; they don't understand the problem and we've given them no reason to. If we moved the text client to a threaded view, there would (quite justifiably) be an uproar.

Blog rooms are a different animal. In a blog room, we *need* the threads maintained, to properly associate comments with their respective blog posts.
Initially, we made it so that only the blog owner can make a top-level post; all others can only reply. This is easy to enforce in the text client, since it simply displays a message explaining why you're only allowed to reply if you try to do "<E>nter-message". And that's why the experiment is targeting blog rooms only, at the beginning. At the very least, we might be able to build blogs that anyone can post new entries to, without making a big mess.

2020-05-25 10:32 from darknetuser
Whatever you do, don't make it more inconvenient for regular people to

use the client for the sake of making it safer for dumb users :-)

Damn, that rules me out then. B^P

Off-the-wall suggestion...

Leveraging something like [n]curses, could certain rooms have a flag set to use a sort/select view and others be left thread-lesss? I know this would segregate Citadel-client loyalists into only using unthreaded rooms, but would at least offer the feature.

We've had a curses-integrated client before ... it became unwieldy and gave people a lot of build problems. As you know, we're trying hard to reduce build problems :)

My other thought was that perhaps we can make two different types of rooms, "linear" and "threaded" which will give the user different prompts as they navigate through. Perhaps the only difference in the text client would be that it gives the nag prompt when someone hits "<E>nter". And/or in WebCit it could present in a more traditional "web forum" view, where the first screen shows a summary of all active threads. <shrug>

Not happening yet, there's too much to do. I've got webcit-ng to finish first :)

Upon login today, I just realized something that differs a tad from "classic Citadel". During the login sequence, the point where it notifies the user that there is a new mail message shows up before the onslaught of the Lobby's conversation, not just prior to the prompt.

The <G>oto -> <N>ew flow ends up putting the user into the Mail> room anyway, but I thought it would be nice for the user to see this a little more obviously since there is a lot of screen scroll on busy Lobby> rooms.

I've got to admit, I read the entire room, then typically <E>nter my response, especially in the text client, and it is out of habit.

That's the original flow as it was built nearly 40 years ago, and all old-school Citadel afficionados are used to it. You land in a room, read everything new, and then whack the <E>nter key and decide what to say. I don't blame anyone for wanting to do that ... after all, the classic view is *built* for that ... it simply doesn't map well to other views.

Citadel's classic view simply wasn't built for "topics" and "threads". It was built for free-flowing conversation, and it still does that amazingly well. To force the use of "topics" and "threads" everywhere would certainly turn it into "not Citadel". The task at hand, then, is to figure out how -- and more importantly, *where* -- to compromise.

It's easy when rendering a web view, because the presentation gives the user a visual cue on how to interact with it. A room that displays as a blog is going to have comment boxes attached to each blog entry, and the "Enter message" button at the top has been replaced by "New blog post". A room that displays as a normal message board, on the other hand, has "Reply" and "ReplyQuoted" buttons next to each message, so they're used some of the time. Someone whose first and only experience with Citadel is on WebCit might use those buttons more than someone coming over from the text client ... but the "Enter message" button is still there on the top of the screen, so it could go either way.

I think the compromise will eventually be to offer two types of message board rooms. One would be the existing "linear" view that we all know and love, because again, it is excellent for free-flowing conversations. The other would be a "threaded" view, which would be appropriate for rooms like Citadel Support where you have threads whose conversations are tightly related to a specific topic. Here at Uncensored we'd stick with the "linear" view for most rooms. In a "threaded" room, a text client user who hits "<E>nter message" would then get the warning that they're in a special kind of room and they'd be starting a new topic, and do they really want to do that.

So that's my current thinking. Comments/suggestions?