life after Windows....

In article , aracari
wrote:

This will include deciding what program functions you want the
user to have access to. Those which are not made available through
the GUI can often be accessed on the commandline used to start
the program.

ugh. hidden features are obnoxious. if it's important enough to
implement, why hide it from the user?

Wise up friend. You're obviously not very well clued.

ah, insults. that always bolsters an argument.

Many functions are either deliberately hidden because users cannot
be trusted to use them properly -or- the programmer leaves them
out for reasons of development speed, laziness or whatever.

if users can't be trusted to use certain features, why are they even in
the app at all? and if the features are hard to use properly then the
interface needs to be rethought. you are basically justifying bad ui.

A fair number of programs in Windows and also many application
programs have functions which are only available via the
commandline used to start it. I posted one example in this thread:

Here it is again:
"C:\Program Files\freepops\freepopsd.exe" -t 6

The additional parm "-t 6" tells freepops that I wish the program
to support up to 6 webmail accounts (default = 4). The only place
to specify that parm is when the program is started.

why is it limited to 4 in the main ui and 6 with a hidden option? if
it can support 6 accounts, why not offer that capability to everyone?
if 4 is stable and 6 is buggy, then fix the bugs rather than offer it
as a hidden option that might crash.

There are many other examples of this. Irfanview has got several
dozen commandline options which can be used to start it etc.

yes, there's plenty. that doesn't mean it's a good thing.

aracari to e-mail me wrote:
'Ray Fischer' wrote this:

aracari to e-mail me wrote:
'nospam' wrote this:
wrote:

the point is that the original mac os did not have a command line.

Fine, I have no problem with that.
Nevertheless, the GUI will have been created after writing the
program function code itself (or normally would be).

there's no reason for one to be before the other. it all depends on
what the app does and how the developers wish to implement it.

The normal cycle is to design the program you want to create
and then set about writing/testing it. That is often an iterative
process which might take some time.
When you've finished and you've got the program doing exactly
what you want, you might then create a GUI for it.

Hmmm. With a great many commercial applications the UI is an integral
part of the program and is included as part of the overall design.
Grafting on a UI afterward typically results in crap.

It probably depends how well the program is designed and written.

You cannot do a proper design without considering the user interface.

eg: years ago I did some APL programming and there were two
styles for this:

APL programming is irrelevant. If that's the limit of your
programming experience than you have no basis for your opinions.

1.a huge single program which changed the world in one go but
was virtually impossible to further develop or maintain -or-
2.breaking it down into lots of small logical functions, which
were then collated by using a new top function which ran all
the others. This method was always much easier to maintain.

The former is what inexperienced programmers do, the latter is
for the professional guys.

These days the 2nd approach is what the newbies do. Professional
software engineers are a couple of steps beyond that.

Exactly the same applies to complex DOS batch files etc.
I wrote a large series of 4DOS batch files some years ago which
turned my 4DOS system into a 100% menu driven machine and never
saw the DOS prompt. I used up to 50 seperate batch files for this
to avoid over complexity and ensure easy maintenance.

I routinely add thousands of lines of code to systems that have
millions of lines of code.

This will include deciding what program functions you want the
user to have access to. Those which are not made available through
the GUI can often be accessed on the commandline used to start
the program.

But if you don't know what you're going to allow the user to do
then how do you know what program functions to develop?

At the time of program development you will know ...or you
haven't done the design phase thoroughly.

Design is part of development.

--
Ray Fischer

aracari writes:

Which was one reason for MS creating the GUI: "make it easy"
and "make it pretty".

They do the same thing with Windows servers. Unfortunately it has more
negative effects with servers than with desktops.

aracari to e-mail me wrote:
'Ray Fischer' wrote this:
aracari to e-mail me wrote:
'nospam' wrote this:
wrote:

the point is that the original mac os did not have a command line.

Fine, I have no problem with that.
Nevertheless, the GUI will have been created after writing the
program function code itself (or normally would be).

there's no reason for one to be before the other. it all depends on
what the app does and how the developers wish to implement it.

The normal cycle is to design the program you want to create
and then set about writing/testing it. That is often an iterative
process which might take some time.
When you've finished and you've got the program doing exactly
what you want, you might then create a GUI for it.

Hmmm. With a great many commercial applications the UI is an integral
part of the program and is included as part of the overall design.
Grafting on a UI afterward typically results in crap.

It probably depends how well the program is designed and written.

You cannot do a proper design without considering the user interface.

eg: years ago I did some APL programming and there were two
styles for this:

APL programming is irrelevant. If that's the limit of your
programming experience than you have no basis for your opinions.

1.a huge single program which changed the world in one go but
was virtually impossible to further develop or maintain -or-
2.breaking it down into lots of small logical functions, which
were then collated by using a new top function which ran all
the others. This method was always much easier to maintain.

The former is what inexperienced programmers do, the latter is
for the professional guys.

These days the 2nd approach is what the newbies do. Professional
software engineers are a couple of steps beyond that.

Exactly the same applies to complex DOS batch files etc.
I wrote a large series of 4DOS batch files some years ago which
turned my 4DOS system into a 100% menu driven machine and never
saw the DOS prompt. I used up to 50 seperate batch files for this
to avoid over complexity and ensure easy maintenance.

I routinely add thousands of lines of code to systems that have
millions of lines of code.

This will include deciding what program functions you want the
user to have access to. Those which are not made available through
the GUI can often be accessed on the commandline used to start
the program.

But if you don't know what you're going to allow the user to do
then how do you know what program functions to develop?

At the time of program development you will know ...or you
haven't done the design phase thoroughly.

Design is part of development.

--
Ray Fischer



--
Ray Fischer

In article , aracari
wrote:

Often an undocumented feature is written into a program for use
by support staff or for special purposes, not for everyday users.
It wouldn't make sense to include them in the GUI for the reason
you and others have already stated: "users can't stop fiddling".

true, but that doesn't mean it can only be accessed via command line.

A fair number of programs in Windows and also many application
programs have functions which are only available via the
commandline used to start it. I posted one example in this thread:

Here it is again:
"C:\Program Files\freepops\freepopsd.exe" -t 6

The additional parm "-t 6" tells freepops that I wish the program
to support up to 6 webmail accounts (default = 4). The only place
to specify that parm is when the program is started.

why is it limited to 4 in the main ui and 6 with a hidden option? if
it can support 6 accounts, why not offer that capability to everyone?
if 4 is stable and 6 is buggy, then fix the bugs rather than offer it
as a hidden option that might crash.

1.support for 6 accounts is not buggy.

if it's not buggy, why not let everyone benefit from it?

2.the default of 4 isn't even included in the GUI! It just
defaults to that number when the program is started.

why not offer it directly instead of a hidden option?

I cannot say why but...

2a.perhaps the author considered that 4 was ample in the program's
first release, but later learned that some people wanted more. He
then wrote a quick fix to increase the number to whatever the user
wanted, and issued the parm option to achieve it.

if that's the case, then he didn't want to take the time to properly
revise the software. what else did he skimp on? that does not lend
confidence in the product.

and it's actually 5, according to the docs:
http://www.freepops.org/en/files/html-manual/node5.html

2b.otoh maybe each additonal account consumes system resources
and he wanted to limit that in the early days for average users.

if it's limited, then why offer the option? and if the limitations are
gone, why is the option not in the main ui?

My main point was to show that many programs have options which
are only available through parms on the start-up commandline, not
through the GUI.

sure, but that doesn't mean it's a good idea. there are also a lot of
programs that have a horrible ui, are slow in execution, use more
memory than they need to (or worse, leak) and other flaws.

Commandline parms reduce the time necessary to complete the
GUI program development without limiting its abilities.

in other words, the app is rushed to market and released prematurely?
and that's supposed to be a good thing?

more importantly, the command line is not a proper api.