why we don't need a (n ultimate) GUI design tool
Plugh!
- my father wrote I-F with WordStar under CP/M. And his father before
him. On an abacus!
- GUIs are for wimps (windows, icons, mice & pointers).
- if we really needed it, it would already exist.
- it's probably full of bugs.
- name me one piece of i-f developed by this entirely new system which
has ever won the annual competition?
- it doesn't support Inform yet, so I wouldn't even deign to use it as
a map and plot development tool or actively contribute to its
devlopment so that it can support Inform.
- it doesn't run under Linux yet and I won't install Wine.
- it's probably not Y2K compliant.
<insert your personal prejudice here. Don't bother to offer any
helpful suggestions. Don't forget, it's laways easier to tear down
than to build up>
Seebs
Plugh! <pl...@plugh.info> wrote:
><insert your personal prejudice here. Don't bother to offer any
>helpful suggestions. Don't forget, it's laways easier to tear down
>than to build up>
Speaking of which, you don't seem to be very encouraging of input from
people who might have some of these concerns, and have the ability to
help resolve them.
-s
--
Copyright 2004, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
David Whyld
thought it seemed like a pretty nifty tool. But as it was a beta version and
not particularly user friendly, I decided I'd wait for the finished version
before I tried to write a game with it.
Posting these sorts of comments isn't doing Plugh any favours.
"Plugh!" <pl...@plugh.info> wrote in message
news:68bd0e8.04021...@posting.google.com...
Andrew Plotkin
Do you have refutations for any of these arguments? Exaggerating them
to the point of absurdity is not a refutation.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Coorlim
I dunno. It seems kinda... pointless. I guess having a cross platform GUI
IF runner might be useful, but in general a single IF project will be in a
single language. If you want to use a GUI that badly, I suppose that there
are some out there already that do much of the work for you.
The biggest issue I'd have with a GUI + coding approach is that GUI has to
take a lot of things for granted about the way the program works. If I'm
going to have to code edit much of the way the GUI automaticly does things
for a particular project, I think I'll just skip the GUI all together...
-Coorlim
Plugh!
> In article <68bd0e8.04021...@posting.google.com>,
> Plugh! <pl...@plugh.info> wrote:
> ><insert your personal prejudice here. Don't bother to offer any
> >helpful suggestions. Don't forget, it's laways easier to tear down
> >than to build up>
>
> Speaking of which, you don't seem to be very encouraging of input from
> people who might have some of these concerns, and have the ability to
> help resolve them.
Sorry, that was a late night post. It was meant to be tongue in cheek.
I apologize if it did not come across that way.
Btw, do you have any ideas for usch a tool? If so, please add them to
the other thread. Thanks.
Plugh!
> I actually downloaded the beta version of Plugh several months ago and
> thought it seemed like a pretty nifty tool.
> But as it was a beta version and
> not particularly user friendly,
Could you plesaae tell me if there is something which you would like
me to change? By "not particularly user friendly", do you just mean
that it's still missing a help file, hotkeys, etc? Or is there
something else which I need to address? Thanks in advance for any
input.
> I decided I'd wait for the finished version
> before I tried to write a game with it.
Ok, I guess that I have to knuckle down and get it finished. Thanks
for the spur.
Plugh!
> Here, Plugh! <pl...@plugh.info> wrote:
> > This thread's for the nay-sayers ...
> >
> >
> > - my father wrote I-F with WordStar under CP/M. And his father before
> > him. On an abacus!
> > - GUIs are for wimps (windows, icons, mice & pointers).
> > - if we really needed it, it would already exist.
> > - it's probably full of bugs.
> > - name me one piece of i-f developed by this entirely new system which
> > has ever won the annual competition?
> > - it doesn't support Inform yet, so I wouldn't even deign to use it as
> > a map and plot development tool or actively contribute to its
> > devlopment so that it can support Inform.
> > - it doesn't run under Linux yet and I won't install Wine.
> > - it's probably not Y2K compliant.
> >
> > <insert your personal prejudice here. Don't bother to offer any
> > helpful suggestions. Don't forget, it's laways easier to tear down
> > than to build up>
>
> Do you have refutations for any of these arguments? Exaggerating them
> to the point of absurdity is not a refutation.
peece of my own devising, not "arguments". If what you are asking is
whether I can prove that a GUI based development tool would be useful
and might even convince some to leave their text editors, then there
is only one way to settle that. I'd better get coding.
Plugh!
> I guess having a cross platform GUI
> IF runner might be useful, but in general a single IF project will be in a
> single language.
That's true, but the point is that if we do have a suoer-duper i-f
development tool, it would be unfair to limit it to users of one
particular i-f language. I doubt that any given user will produce
multiple i-f lamguages, but I'd like the tool to be available to all.
> If you want to use a GUI that badly, I suppose that there
> are some out there already that do much of the work for you.
None that I know of - do you?
> The biggest issue I'd have with a GUI + coding approach is that GUI has to
> take a lot of things for granted about the way the program works. If I'm
> going to have to code edit much of the way the GUI automaticly does things
> for a particular project, I think I'll just skip the GUI all together...
I'm not sure that I understand you 100%, sorry. But it is certainly a
prime directive that the tool not restrict the user in any way, if
that is what you mean.
Thanks for your feedback.
ken franklin
Having looked at Plugh a while back and thought what an excellent project it
is, but that it was attempting to present everything immediately to the
author. The interface might benefit from having different levels for users,
even if it were just simple and advanced.
With the simple version many of the options would not be presented to the
user, they would create their building blocks from a slimmed down set of
options. As the programme would be working on the same filetype, with the
other possibilties being set to sensible defaults, the user as they became
more confident would try switching to the advanced setup and hopefully make
use of the additional features available.
The simplified interface might also be useful to experienced users who want
a way of quickly setting out the game map, before getting down to writing in
their normal editor that they have grown attached to.
This is in no way a criticism of what looks to be an excellent project,
merely a suggestion about how it could be made more accessible, particularly
to those new to IF.
Good luck.
KF
"David Whyld" <m...@dwhyld.plus.com> wrote in message
news:JL8Xb.3725$Y%6.49...@wards.force9.net...
Roberto Grassi
if you believe in what you're doing, go on. :D
Rob
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
David Whyld
> Could you plesaae tell me if there is something which you would like
> me to change? By "not particularly user friendly", do you just mean
> that it's still missing a help file, hotkeys, etc? Or is there
Not user friendly meant in the sense that the interface could certainly use
some work on. The Navigation menu continually got in the way of other
menus - wouldn't it be better stuck to the top or side of the screen as a
standard toolbar? And there was also a noticeable delay when clicking on the
Room or Actor options which you don't tend to expect when you've got a gig
on RAM on your hard drive.
Also from what I gather, Plugh is written mainly for non-programmers who
want to produce Tads games without the hassle of learning the language.
Correct? As such, features like "aboutPrep", "betweenPrep", "outhideStatus"
and several dozen others aren't going to mean a lot to the majority of
people using this program. A programmer would understand them, but as Plugh
isn't aimed at them that isn't going to help anyone. Helpful pop-ups bubbles
explaining what they meant would be a BIG advantage. Sure, I could download
a Tads manual and find out what they mean but pop-ups would be better.
The main reason I didn't make a better effort to get a game done was,
naturally, the fact that Plugh isn't finished. I don't want to spend the
next 6 months of my life writing a game for a program that is still in the
beta stage. Finish it though...
Coorlim
Hrm... I thought Plugh was designed as a labor saving device for
programmers... mebbe it can be both.
Plugh!
> Not user friendly meant in the sense that the interface could certainly use
> some work on. The Navigation menu continually got in the way of other
> menus - wouldn't it be better stuck to the top or side of the screen as a
> standard toolbar?
The Nav Bar floats. You can drag it to whichever position you like. I
suppose I could add some "collision avoidance", to prevent the user
positioning it over the main screen.
> And there was also a noticeable delay when clicking on the
> Room or Actor options which you don't tend to expect when you've got a gig
> on RAM on your hard drive.
Do you mean a gig or ram + plenty of room on your hard drive? In any
case, it sounds like you have a fast machine - which suprises me, as I
don't notice any such delay... I will do some timing & see if I can
improve anyhting.
> Also from what I gather, Plugh is written mainly for non-programmers who
> want to produce Tads games without the hassle of learning the language.
> Correct? As such, features like "aboutPrep", "betweenPrep", "outhideStatus"
> and several dozen others aren't going to mean a lot to the majority of
> people using this program. A programmer would understand them, but as Plugh
> isn't aimed at them that isn't going to help anyone. Helpful pop-ups bubbles
> explaining what they meant would be a BIG advantage. Sure, I could download
> a Tads manual and find out what they mean but pop-ups would be better.
Yoicks! That might be tough to implement. *But* it is a very good
idea. I have noted it & will add it either the to-do list or the wish
list. Hmm, teh more I think about it, the more I like it.
> The main reason I didn't make a better effort to get a game done was,
> naturally, the fact that Plugh isn't finished. I don't want to spend the
> next 6 months of my life writing a game for a program that is still in the
> beta stage.
You are absolutely correct.
> Finish it though...
Asap! And when I do, I hope that you'll beta test.
Thanks for the feedback.
Plugh!
> "David Whyld" <m...@dwhyld.plus.com> wrote in message
> news:vOsXb.4584$Y%6.55...@wards.force9.net...
> >
> > want to produce Tads games without the hassle of learning the language.
>
> programmers... mebbe it can be both.
Aye, there's the rub. It tries to be all things to all men, which is
probably not such a good idea.
Yes, it can attract newbies, becuase they can produce i-f with a great
deal less coding, but I also want the old hands to use it. Hence the
requirement that anything which can be coded with a text editor should
be producable with Plugh!
I do like the idea of an "expert mode" which toggles some of the more
esoteric features.
Plugh!
> I can certainly see where David Whyld is coming from with this.
>
> Having looked at Plugh a while back and thought what an excellent project it
> is, but that it was attempting to present everything immediately to the
> author. The interface might benefit from having different levels for users,
> even if it were just simple and advanced.
Wow, good idea Ken. Sometimes one is too close to the problem to see
it. That would never have occurred to me, but now I really like the
idea. Thanks.
Plugh!
> Go on Plugh,
> if you believe in what you're doing, go on. :D
> Rob
Thanks for the encouragement, Rob. Yes, I really do believe in it.
You've got to have a dream. If you don't have a dream, how you gonna
have a dream come true?
I am a professional software engineer and am embarrassed about how I
approached Plugh! I really thought it would be a one month project or
so, so didn't bother to design it. Thus it grew organically, and
required a few rewrites.
Next time, I'd like to do it properly. Specification and design is
everything, coding is nothing. I'll like to get a bunch of suggestions
(please, please contribute) and work for as long as it takes to design
the program (I'm happy to collaborate on the design; in fact, I'd
prefer not to do it all myself). After that, it's just a matter of
coding & hopefully there would be some volunteers.
Uli Kusterer
pl...@plugh.info (Plugh!) wrote:
> Thanks for the encouragement, Rob. Yes, I really do believe in it.
> You've got to have a dream. If you don't have a dream, how you gonna
> have a dream come true?
Use someone else's dream? :-)
> Next time, I'd like to do it properly. Specification and design is
> everything, coding is nothing. I'll like to get a bunch of suggestions
> (please, please contribute) and work for as long as it takes to design
> the program (I'm happy to collaborate on the design; in fact, I'd
> prefer not to do it all myself). After that, it's just a matter of
> coding & hopefully there would be some volunteers.
So this message isn't completely wasted. I think you should go with the
Wiki. Yes, I said that I preferred mailing lists, but for keeping design
ideas, a Wiki is definitely the more adequate solution.
And at least it's not a web forum. :-)
Cheers,
-- Uli "not opinionated" Kusterer
http://www.zathras.de
Uli Kusterer
> > author. The interface might benefit from having different levels for users,
> > even if it were just simple and advanced.
>
> Wow, good idea Ken. Sometimes one is too close to the problem to see
> it. That would never have occurred to me, but now I really like the
> idea. Thanks.
One warning: there have been many cases where such multi-level
approaches have caused more harm than good. E.g. the infamous "Simple
Menus" option that hides many useful menu items and suddenly the user
doesn't know how to bring them back when their needs have advanced.
My favorite approach to avoid frightening new users is:
1) Use sensible defaults
2) Keep commonly used features easily accessible
3) Hide rarely used features
#2 and #3 are governed under the 80/20 rule: If 80% of the time the
features people want to use are easily accessible, they won't mind if in
20% of the cases they'll have to open a dialog window or go into a
submenu.
If you apply #1 to #2 and #3, that also means that if you have tab
controls or other multi-page layouts, the first pane should contain
whatever the user will commonly use most.
Apple's old User Interface Guidelines contain a nice chapter on how to
best arrange your menus:
<http://developer.apple.com/documentation/mac/HIGuidelines/HIGuidelines-8
0.html>
I'd also read the other chapters of that book. Even though it is for
the Mac and not for Windows, and thus some things don't apply or are
handled differently, there's still lots of useful information as it
often states the reasons why you should do certain things.
And a nice list of more general things to keep in mind when designing
how your application should work:
<http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHI
Guidelines/XHIGHIDesign/chapter_3_section_2.html>
That should be recommended reading for anyone designing an application,
IMHO.
Cheers,
-- Uli
http://www.zathras.de
Uli Kusterer
> > Helpful pop-ups
> > bubbles
> > explaining what they meant would be a BIG advantage. Sure, I could download
> > a Tads manual and find out what they mean but pop-ups would be better.
> Yoicks! That might be tough to implement. *But* it is a very good
> idea. I have noted it & will add it either the to-do list or the wish
> list. Hmm, teh more I think about it, the more I like it.
I seem to remember vaguely that someone wrote a tool that took the
comments from the adv3 library's source files and turned them into
readable reference documentation. Maybe you could incorporate that?
Ideally, there'd be a short summary in the docs that you could show in
the tool-tip, and you could even show the full documentation in a
separate window when someone types the "help" key or something like that.
HTH,
-- Uli
http://www.zathras.de
Uli Kusterer
> Yes, it can attract newbies, becuase they can produce i-f with a great
> deal less coding, but I also want the old hands to use it. Hence the
> requirement that anything which can be coded with a text editor should
> be producable with Plugh!
I think trying to make it do "IF without coding" wouldn't be too wise
an idea. I'd leave that to specially designed engines like ADRIFT.
Otherwise you have three translations. Once when the user enters her
ideas into the GUI, the second time when Plugh generates code from the
GUI data, and the third time when the compiler turns the code into the
actual game. Two transitions are enough to cause "bugs". Three is asking
for trouble, in my eye.
Instead, I'd try to make it a tool that eases coding. I.e. that
generates code and lets you modify it, and that helps with the general
code design, and with large restructuring measures that would usually
involve a lot of work. Newbies would then be able to create a simple
game with Plugh, then look at the code and understand how it works, and
adapt it to their needs manually.
> I do like the idea of an "expert mode" which toggles some of the more
> esoteric features.
See my other message on why I'm not quite as enthusiastic of this. Modes
are something that need to be very carefully designed to avoid annoying
the user or being a hindrance.
Plugh!
> I seem to remember vaguely that someone wrote a tool that took the
> comments from the adv3 library's source files and turned them into
> readable reference documentation. Maybe you could incorporate that?
> Ideally, there'd be a short summary in the docs that you could show in
> the tool-tip, and you could even show the full documentation in a
> separate window when someone types the "help" key or something like that.
>
Great idea - let's incorporate it.
David Whyld
news:<vOsXb.4584$Y%6.55...@wards.force9.net>...
>
> > Room or Actor options which you don't tend to expect when you've got a
gig
> > on RAM on your hard drive.
> Do you mean a gig or ram + plenty of room on your hard drive? In any
> case, it sounds like you have a fast machine - which suprises me, as I
> don't notice any such delay... I will do some timing & see if I can
> improve anyhting.
>
I've got Plugh installed on an 80 GB hard drive with about 45 GB free so the
delay was strange to say the least.