|
|
| Author |
Message |
| 25 new of 49 responses total. |
other
|
|
response 9 of 49:
| 
Feb 11 08:45 UTC 2000 |
it's not that i can't read them, just that when i enter a new conference, i
want to see:
155 newresponse items
First item 1, last 155
if there's 155 items.
iit's not a big deal. i just want the feel of using bbs to be consistent in
that regard whether i'm new in the conf or not. it just irks me, that's all.
|
remmers
|
|
response 10 of 49:
|
Feb 11 13:31 UTC 2000 |
I don't think it's inconsistent, but perhaps it's a bit
obscure as to what's going on. The concept of "unseen"
items is useful, but Picospan's messages don't tell you
about them.
|
janc
|
|
response 11 of 49:
|
Feb 11 19:16 UTC 2000 |
Hmmm...here's a deeply awful way to make Backtalk-style new-item
configuration work in Picospan:
- Write 'awfulprog' a program which given the name of two
conferences, checks if you have a participation file for the first
one that was created within the last 10 seconds and that you have
no participation file for the second one. If so, it generates a
participation file for the second conference with using Backtalk's
new-user algorithm.
- Rename 'agora' as 'realagora'.
- Create a new conference named 'agora' which contains no items,
allows no item entry, has a blank login and logout files, and has a
conference rc file that looks like this:
unix "awfulprog agora realagora"
join realagora
When a newuser does "join agora" or "bbs agora" Picospan asks them if
they want to join, observer or quit. If they say join, it creates a
participation file for them. Then it runs the rc file which runs
awfulprog. It would be useless for awfulprog to change the current
conference's participation file, because Picospan already has it in
memory, so the changes to the file would have no effect and just be
overwritten when you leave the conference. So instead, it notices that
there is a .agora.cf and it is new, and there is no .realagora.cf so it
creates a new .realagora.cf. The rc file then does "join realagora".
Picospan sees the .realagora.cf file, and happily loads it.
Joining as an observer doesn't work completely right. awfulprog sees no
.agora.cf, so it doesn't create a .realagora.cf, so when the "join
realagora" is executed you get asked again. If you say "observe" again,
then all works well. If you say "join" the second time, you get a
standard Picospan participation file. Slightly flakey things may also
happen if you rejoin after resigning.
People who have "set nosource" set in their .cfonce files won't get
shunted from agora to realagora. They'll just land in the empty agora
conference. They'll have to join realagora manually and live with the
Picospan-generated participation file. However they are probably
sophisticated enough to deal with this.
This proposal should be viewed as 'an exercise in creative kludgery' not
as 'a good idea.' It could probably be improved a bit, and it probably
causes some other horrid side effects that I hadn't thought of, like
breaking the 'check' command.
The alternatives are (1) convince Marcus to change Picospan, or (2)
convert to Yapp, which anyone can customize.
|
gypsi
|
|
response 12 of 49:
|
Feb 11 19:38 UTC 2000 |
Wow...I was lost by the third paragraph, but it sounds interesting. =)
|
pfv
|
|
response 13 of 49:
|
Feb 12 03:59 UTC 2000 |
Sounds ugly as hell, is what it sounds like.
|
other
|
|
response 14 of 49:
|
Feb 12 05:26 UTC 2000 |
i was under the impression that the number of items
displayed as new when newly joining an active conf
was an option which could be set by system configuration
or adjusted by fairwitnesses. i guess what i'd like
as a compromise is to have the option turned off in
conferences other than agora, recognizing that agora
is the default conference for new users, the ones most
likely to be overwhelmed by a huge list of items.
by the time a user makes it into another conference,
it seems to me that that protective measure is of
greater annoyance than value.
i would argue that what is likely to be most of
concern to a new user would be the arcane command
structure of the unix command-line interface, and
not the sheer volume of material contained in any
particular conference. in fact, i would suggest
that presenting a user with the full extent of a
conference's content on first arrival would support
the notion that the conferences are an extensive
and important part of the grex experience and would
have a generally more positive than negative impact.
|
mary
|
|
response 15 of 49:
|
Feb 12 12:31 UTC 2000 |
I agree with Eric.
|
prp
|
|
response 16 of 49:
|
Feb 12 17:15 UTC 2000 |
How about just changing the wellcome message from:
2 new items.
First item is 1 and last is 145.
to:
2 new and 143 unseen items.
First item is 1 and last is 145.
|
prp
|
|
response 17 of 49:
|
Feb 12 17:25 UTC 2000 |
As for helping new users, the help file could be improved. Or maybe intro
could be restarted.
|
pfv
|
|
response 18 of 49:
|
Feb 12 17:52 UTC 2000 |
The help docs truly reek.. Fixing that makes the rest nearly
tolerable.
|
orinoco
|
|
response 19 of 49:
|
Feb 12 19:32 UTC 2000 |
Personally, I would find "2 new and 143 unseen items" more confusing than just
"2 new items." The distinction between 'new' and 'unseen' is a useful one
in terms of getting Picospan to do what you want, but not a terribly intuitive
one.
|
gull
|
|
response 20 of 49:
|
Feb 13 03:37 UTC 2000 |
Re #14: I thought that was true only in Backtalk. We can't really modify
Picospan's behaviour because we don't have the source code. We just license
it from another company.
|
janc
|
|
response 21 of 49:
|
Feb 13 06:10 UTC 2000 |
Well, Marcus wrote Picospan, sold it to another company, which then went
thoroughly and completely out of business. Marcus has source code, but
who exactly owns it is a question beyond my comprehension.
This is currenlty configurable only for Backtalk users.
|
pfv
|
|
response 22 of 49:
|
Feb 13 06:29 UTC 2000 |
I was under the impression BT also had a "back-end" it could
employ..
|
spooked
|
|
response 23 of 49:
|
Feb 13 11:19 UTC 2000 |
I'm thinking, would anyone want to write a more user friendly interface (less
advanced) interface for new users -- might attract them, or certainly not
sitract them away from the conferences.
|
spooked
|
|
response 24 of 49:
|
Feb 13 11:20 UTC 2000 |
distract, sorry.
|
mary
|
|
response 25 of 49:
|
Feb 13 13:06 UTC 2000 |
At some point it may be worthwhile to look into buying
and running YAPP so that Grex has access to its source code.
|
other
|
|
response 26 of 49:
|
Feb 13 22:30 UTC 2000 |
do we have a license for our use of picospan, or did we purchase a copy?
do our legal option allow for the modification of the source code for our own
use, so long as we do not distribute the modified version?
and, would there be a legal issue with our being provided an uncompiled source
code to a program we have the legal rights to run? (again, so long as we do
not distribute)
|
remmers
|
|
response 27 of 49:
|
Feb 13 22:51 UTC 2000 |
One property of the things work now with "unseen" is that
it helps guide users to the active items. I see this as
an advantage. If every item that you've never seen were
treated as "new" the first time you joined a conference,
there'd be no easy way for a user to distinguish currently
active discussions from items that haven't seen activity
for weeks. In a big conference like Agora, there tend to
be a lot of the latter. I can think of some other
conferences to which the same observation applies.
|
remmers
|
|
response 28 of 49:
|
Feb 13 23:05 UTC 2000 |
Incidentally, having source code to a product doesn't
necessarily buy you as much as one might think. Suppose
Grex purchases a source license for XYZ Conferencing
Software, Version 2.1. Some Grex staffers invest a
lot of effort into modifying it so that it does certain
things the way we want.
A year later, XYZ Version 3.0 comes out, with lots of
nifty enhancements, but which doesn't include our own
modifications. What do we do -- upgrade to 3.0 and
modify it for our needs all over again (which might be
a lot of work, depending on how different 3.0 is from
2.1), or stick with a now-obsolete version of the
software?
|
orinoco
|
|
response 29 of 49:
|
Feb 13 23:22 UTC 2000 |
(Right, but if the company that owns Picospan no longer exists, presumably
that means they won't be coming out with any upgrades any time soon)
|
mdw
|
|
response 30 of 49:
|
Feb 14 06:09 UTC 2000 |
Whoa there, I think you people are getting way way carried away.
Let's look at the current situation with PicoSpan. What happens when
you currently join an existing conference is easy to describe. It does
something by default that is very nearly the right thing. & it doesn't
take any work to make it continue to do what it does. That is, it's a
good "80%" solution, and that's important, because it's one of those
compromise cases where it's hard to do a lot better than 80%. Jan has
evidently made a slightly different compromise in backtalk - evidently
he was faced with a UI where it was not so attractive to present a lot
of different options for what to read next, & so wanted backtalk to be
"smarter" about what it showed people. So far, I haven't heard any
evidence that what it does is actually "better"--just "different".
Now let's look at some of the proposals above. One was to make
everything "new". Does this help the newbie in agora? No. Does it
help the long-time user of grex? No. Another suggestion was to make a
selected set of items near the end "new". There were (if I recall
right) 2 sub-proposals for how to do this -- some sort of threshold
selection logic that is likely to be expensive to compute, and a manual
system where the fw selectes what's new. The former is hard even to
describe and has all sorts of fuzzy parameters that are difficult to
characterize. I don't believe it would be possible to come up with an
automatic system that would be materially better than the current sytem.
No matter how you slice it, there would still be "new" and "unseen"
stuff, and in agora especially, you are only increasing the amount of
stuff they see automatically -- which is just just wrong (we already
dump *way* too much automatic stuff on new users.) The latter requires
that fw's maintain that list, which means it's going to be out of date.
It's the same as the "agenda" problem in Confer II.
I think some of you people who are so keen to change things need to
spend some time watching new people actually learn to use grex without
prompting (this means you need to resist the urge to tell people what
they should be doing, even when they ask you), and see what they really
do when they're forced to rely on their own intelligence and what they
see on the screen. Then, you need to do this over & over again, because
*each* person is different. Even this won't do anything to help you see
effective solutions, but it will at *least* show you what some of the
problems are.
So far as seeing effective solutions go, the first hard fact you have to
realize is, for many cases, there *is* no effective solution - computer
conferencing is intrinsically interesting to a very small subset of
humanity. The 2nd hard fact to face is, you can't *tell* someone what
they should do, and expect them to learn. This may be
counter-intuitive, because our entire educational system is designed
around this theory. Nevertheless, it remains the fact that the best way
to learn something is to *want* to solve a problem, and to be open,
creative, curious, and willing to experiment. This is hard to study,
because we're all taught that this is bad, and this is particularly hard
to study in in new people learning to use grex, because they *don't*
want to look stupid in front of you. The last hard to face fact is, in
any system where you are faced with a lot of different people with
different expectations, there is no one answer that will work for
everyone--in fact, there's no one answer that will work for *most*
people. This means you are inevitably in the "filter" business -- you
are designing a system that will catch some people's attention, and piss
a lot of other people off in the process who will go elsewhere. So, one
of the choices you are making when you design a system like this, is the
sort of people you want to attract to the system. I can tell you right
off that the sort of people I wanted to attract when I designed PicoSpan
and newuser for m-net was "smart people who want to yak a lot." If my
goal had instead been "get stupid people to say something at once", or
"get as many people on at once as possible", I might have designed
things very differently. Having said all that, I'll also say that there
are things I would do differently in PicoSpan if I were to do it over
again, in part because we have better computers today, and in part
because I've learned lessons from PicoSpan. I hope to get the chance to
do just that someday - it's one of those "get around to it" things.
|
other
|
|
response 31 of 49:
|
Feb 14 07:18 UTC 2000 |
|
i'm trying to figure out what's possible here.
i'm also expressing my particular tastes, and trying to
see if making meeting them an option is part of the above.
i am basing this on that as-yet-unaltered perception that the
feature i'd like to see adjusted is admin-adjustable and not
hard-coded into picospan. should i interpret response 30 as
contravening that notion?
|
|
remmers
|
|
response 32 of 49:
|
Feb 14 11:49 UTC 2000 |
As far as I know, it's hard-coded into Picospan.
Re resp:27 - right, not an issue with Picospan. My comment was
directed at the notion of having source code for a product that's
still under active development, like YAPP. Keeping a local
version in sync with new releases of the product is not a small
task.
|
mary
|
|
response 33 of 49:
|
Feb 14 21:59 UTC 2000 |
I think it's probably time too that Grex have a clear understanding
of our use of Picospan. Does Grex own anything? Is source available
to Grex? If the source is available could changes be made even if
Marcus didn't like the changes?
I'm not asking this in a hostile tone. I just think it would be best
to have how this works understood by all.
|