Conference bulova::decw_jan-89_to_nov-90

    Well, you are just outlining something many many people have been
    screaming all along since the early days of DECwindows: DECwindows fell
    flat on it's face in the customization space (as well as in the
    printing space, but that's another issue). Time constraints resulted in
    zero architectural work being done in the customization space, period.
    The real question is whether the market will give us time to make up
    for our mistakes, and whether the market wants anything at all. I know
    for sure that Open Look offers things which will make us look very
    stupid; only time will tell whether they'll use this as a competitive
    advantage.

    Denis.

> I seem to be hearing a new tune sung lately, mostly from the various
> OOTB groups when it comes to asking why I can't customize my interfaces
> more to the way I want them. 
    
    Well, re the moving of the declaration of resources from defaults files
    to UIL, I can't say I'm too unhappy about that in a lot of cases, but I
    do think the app. should allow as many as reasonable to be customized.
    
    For instance, for Calendar V2 we tried to provide a decent UI for
    customizing as much as possible.  Admittedly more could be added, but
    those resources that can't be modified directly are still in the app.
    defaults file, mostly fonts, colours and default file specs.  We could
    do with "Customize" options for these too, but ran out of time.
    
    So, I think apps should migrate from using resource files to using a UI
    for customizing those bits that they can, although I don't see a reason
    for hardwiring (in UIL for example) resources that can't be customizing
    via a reasonable UI.  Moving things like widget positions from defaults
    files to UIL (or calculating them dynamically) is one thing, but fonts
    etc should remain in defaults files until a better method exists, not
    just hardwired.
    
    Regards,
    
    Marios

    I have to admit, DECW$calendar is the best of the OOTB appls, and has
    done a very good job of allowing the user to modify what "is possible".
    The worst one that comes to mind is DWMAIL.
    
    -Ken

    The question is; Will Marketing slow up long and soon enough to
    let SW Engr. catch up?
    

>    I have to admit, DECW$calendar is the best of the OOTB appls, and has
>    done a very good job of allowing the user to modify what "is possible".
>    The worst one that comes to mind is DWMAIL.
    
	OK, Ken, what do you think is wrong with DWMAIL? We can't very well
	fix it if you don't tell us specifically what you think is wrong...

	Mike

        re .2
        
        UNfortunately DWcalendar is quite comformfortable, but doesn't
        want to know about non workstation access. So if, I wan't to check
        when my first appointment is on monday, I will have to drive to
        the office, even though I am currently dialed into my workstation.
        
        re .3
        
        Gotta agree with .5 (I haven't been able to think of anything in
        dwmail that I haven't been able to customize. THe only thing that
        is lacking is good docs on what is what in the resource
        hierarchy.)
        
        q
        
        

    Re .6:

>    UNfortunately DWcalendar is quite comformfortable, but doesn't
>    want to know about non workstation access. So if, I wan't to check
>    when my first appointment is on monday, I will have to drive to
>    the office, even though I am currently dialed into my workstation.

    Well, you know, it's not that DECwindows Calendar doesn't want to know
    about non workstation access, it's that the Corporation doesn't think
    it's worth it. If you have some dollars which you don't think you'll be
    able to spend, we'll arrange something! Or maybe we should cross charge
    your cost center? ;-)

    Denis.

    Publish the datafile spec and you might find it gets done for you.

        re .7
        
>    Well, you know, it's not that DECwindows Calendar doesn't want to know
>    about non workstation access, it's that the Corporation doesn't think
>    it's worth it. If you have some dollars which you don't think you'll be
>    able to spend, we'll arrange something! Or maybe we should cross charge
>    your cost center? ;-)
        
        Why is it then, that the rest of the software development groups
        in the corporation seem to think that retaining CCT access is
        worth it.
        
        re .8
        
        I wish they would. This has been a subject of debate in the
        decwindows calendar notesfile for months. It seems that the
        decwindows calendar developers feel that there is no-one else in
        the corporation competent to understand their datafile format.
        
        sigh...
        
        q
        

>>    Well, you know, it's not that DECwindows Calendar doesn't want to know
>>    about non workstation access, it's that the Corporation doesn't think
>>    it's worth it. If you have some dollars which you don't think you'll be
>>    able to spend, we'll arrange something! Or maybe we should cross charge
>>    your cost center? ;-)
>        
>        Why is it then, that the rest of the software development groups
>        in the corporation seem to think that retaining CCT access is
>        worth it.

    Calendar is bundled and free, and is only being offered as a teaser for
    a real product which DEC will sell. Enter CLT::DECPLAN in your notebook
    to learn more; therefore, it has been decided that offering a CCT
    interface was not a goal. Period.

>                                                  It seems that the
>        decwindows calendar developers feel that there is no-one else in
>        the corporation competent to understand their datafile format.

    With all the respect I owe you Peter, this is a disgusting attack on
    the developers which completely misses the reasons why the publication
    of the Calendar Data Format has been delayed. I have no idea why you
    said such a thing. If you wish to continue this discussion, on friendly
    grounds that is, please use the CASEE::DECW$CALENDAR conference, or get
    in touch with me off line.

    Denis.

RE: not providing character cell interfaces.

If the CCT interface is dead, then why are the TP products spending millions of
dollars to build the best, lowest cost per seat character cell interfaces. 

Certainly when workstations are the cost of VTxxx terminals, then we'll say that
CCT vs. DECwindos is a dead issues. Until you can deliver me a < $1000 DWT,
CCT will still be a big issue. Take a look at the VTxxx volume forcasts for this
next year - it's a big busineess in it's self.

Besides do I really need a mouse, color screen with fancy fonts, and all this
neat window stuff just to get the person's name, address, the name of the thing
he wants to order, and his credit card number? Also can a workstation solution
provide lowest system cost for a given transaction rate?

DECwindows is really neat, but it still doesn't provide a solution to all of the
application spaces which we need to fill. People will still have CCTs for a long
time to come, I predict that we'll start hearing loud demands for CCT interfaces
to all of our existing DECW applications very soon.

James

well, if you feel that strongly, why don't you take your case
to the people who make the decisions? --  that's product management.

ranting at the individual engineers in this file won't help anyone
at all.  they have clearly stated that they have been told not
to do a character-cell-terminal interface to the bundled calendar
utility.

RE: .11

I heard the same arguments put forward about 8 years ago for retaining teletype
compatibility in products.

--PSW

Ahh, yes, but you will notice that you can now buy video terminals much
cheaper than you can buy Teletype terminals.  (Used ones don't count.)

    Re .11:                              
    
    The best argument in favor of character cell is that it works at 2400
    baud. X doesn't. Note this argument still holds, even if a workstation
    is as cheap as a VT.
    
    Also, people keep on buying not just real VTs, but also PCs without
    mice and without network interfaces. 
    
    Another reason character cell survives is that it's easier to program.

>And most of our non-graphic products are still teletype-compatible, including
    
Maybe someday VAX Notes will be DECwindows-compatible too...

    

Re: .13:

> RE: .11

> I heard the same arguments put forward about 8 years ago for retaining teletype
> compatibility in products.

And most of our non-graphic products are still teletype-compatible, including
VAX Notes and ALL-IN-1.  ;-)

Steve (who is entering this in DECwindows and will severely injure anyone who
tries to take his workstation away.)

.17 is a reply to .18 (let's do the time warp again).

Re: .17

> Maybe someday VAX Notes will be DECwindows-compatible too...

You mean these four windows on my screen titled "VAX Notes" are just a figment
my imagination?  :-)

Steve

       RE: .17
       
       	And maybe someday people will catch up with what's out there..
       VAX Notes has a DECwindows interface NOW and is CDA compliant NOW.
       ie: You can put DDIF files in notesfiles..
       
       							mike

    
      you know how slow those ponies take getting here...
    
    

    re .20, .21
    
    I thought that .17 was a sly reference to how dreadful DECwindows notes
    is when compared to the CCT notes. It's really a lot easier to put
    notes into a terminal window than to struggle with the DECwindows
    interface.
    
    re Calendar and CCT interfaces:
    
    With regard to CCT interfaces in general, I agree that most
    applications should minimize the amount of terminal stuff they do. But.
    There are some applications that really ought to have a minimal (and I
    stress the word minimal) CCT interface. Calendar is one of these.
    
    I find it rather frustrating that I have to be in the office to check
    my calendar. I like the application -- it beats the heck out of a
    Day Timer because I'm not as apt to lose it (I only have to worry about
    disk crashes) -- but I would *love* to be able to dial in to my
    workstation and find out if that meeting I have tomorrow afternoon is
    at 1:30 or 2:30. That's about all I want -- to be able to *check* the
    calendar from a modem if I'm out in East Overshoe.
    
    	Jon

RE: .22

Hear Hear (on both counts: Dreadfullness of entering notes via DW interface with
it's lack of automatic line wrapping and wanting to be able to check the 
calendar remotely from a dumb terminal -- maybe we need to organize a raiding
party and go kidnap the calendar datafile specs!)

DECW$Calendar is a freebie that demonstrates the great potential of DECwindows.
DECW$MAil is a totally new interface which offers many new functions not
available with Mail.  A non-DW calendar interface would be a new utility;
what is the business justification for NOT doing other DW works in order to
develop this new utility?  Surely by now you are aware of the format for the
request:
	What functions are required?
	What is the business impact of this new functionality?
	What is the impact of not doing this?
	What are the strategic implications of this functionality?

Given that the primary purpose of DECW$Calendar is to make DECwindows as a whole
more attractive, it isn't clear that there is any major reason for an alternate
interface.

On the other hand, DECplan has a much broader purpose.  This is intended to be
a general purpose planning and scheduling facility.  As such, they have
recognized the requirement for some level of non-DW interface and are providing
a DCL command line interface and a callable interface.  DECplan provides
all the functionality of DECW$calendar plus much more.

Similar discussion applies to a non-DW interface for DECW$Paint and
DECW$cardfiler and so on.

I am not allowed to mention names ;^)...but a few Ultrix hackers have
cracked the dxcalendar code.  The calendar can now be read from 
terminals.


Kris...

"Software facism never thrives!"

RE: .24

All of the business things you say make plenty of sense.  All I'm asking for 
(and I suspect all any of us are really asking for) is a way to use calendar
from a terminal.  I don't care if it's pretty, supported, full-featured or
any of that crap.  I'm talking about an internal hack that allows those of
us inside DEC who've come to entrust our entire lives to DECW$CALENDAR a way
to find out what meetings we are missing from home.  Where's the business
justification for NMAIL?  How many of us could stand it on a daily basis
without NMAIL?

    I'll take a fast CCT interface over a slow DW interface any day.
    
    That's a terrible reason to "require" a CCT interface, but whatsa
    fella to do?

re: "calendar format cracked"

Is it the same file format on VMS?  Is the program portable?  
Nearly portable?   (I'll volunteer to waste some time porting
it).

---

dave

But the unnamed individuals cracked the V1 format which will be going away
real soon.

Re: .22, .23:

Yeah, reading notes is great, but entering them is a real pane.  I finally
solved the problem by keeping an EVE window open all the time.  Then I
simply enter my reply in EVE, select all, cut, paste, and away we go. 
Works great for DECwindows Mail, too (although the problems there are not
as bad as in Notes).  I've even been known to edit something in EVE and
paste it into a terminal window running (gasp!) ALL-IN-1.  Now if we could
just get DECwindows EVE to allow us to call DECspell . . . :-)

Steve (who is dialed in from home and, therefore, using a CC terminal
interface to enter this (from a Macintosh, no less)).

    Allright, some answers and a couple of statements to help everybody
    cool down:

    - If you would like an official, supported CCT interface to Calendar,
    please use appropriate channels to ask for it. VMS and Ultrix
    DECwindows Product Management collect requirements before launching a
    new development thread; their request for requirements is usually
    posted in this conference and widely distributed.

    - All Calendar developers are absolutely convinced that a CCT interface
    for Calendar is goodness, but no one in a position to tell us what to
    do has ever asked for it. That's the way it is. A database interface
    specification exists, as part of the project's private documentation,
    and is currently being updated to reflect some last minutes changes
    made to it. This specification MAY be become open to DECcies, once the
    project starts phasing down; it will NOT be supported, or in other
    words, we'll change it whenever we have to.

    - It is true that the V1 database format has been cracked by unnamed
    individuals (and customers too...). That's cool, but as usual you have
    to realize that you may be in trouble  when the next release of
    Calendar comes along. That's the statement we issued to customers.
    
    Going back to work,
    Denis.    

    Re: .5   What's wrong with DWmail? Why can't I change the font to something
I don't have to squint to read? Why can't I read the next mail without having 
to use the mouse? Shall I go on?  It's not only with DWmail that is the problem,
and I didn't want to single out Dwmail, or give kudos to other projects, but
that's what happened. All I ever meant to say was summed up in a previous
reply, "I'd rather have a CCT interface, over a lousy DW one." If the DW one
is really sexy, it still might be "lousy" in the sense that it is actually 
more of a pain to use. Most of the interfaces that have kept the key bindings
like Notes or VTX are VERY usable without having to touch the mouse, but
provide some nice added value when using the DW interface. Nuf said.

   RE: DWcalendar.and .30 C'mon fork it over, and forget you ever released it.
Not a single peep out of anyone on the net I know if you folks decide to 
change the interface (again), unless of course, you don't release another
olb and update spec. :-)

-Ken

Today it's calendar we want to run from home, but as I look at where 
DEC is going there'll be nothing but calendars before long.  Layered 
products are DW'ing as fast as they can.  It's only a question of time 
before most of what we do will be based on DW.  Now, not many of us
have an extra $10k to buy an standalone pvax with backup to work on at
home. Also, the rumors I hear are that if DEC ever did develop a DW
terminal (Program announced, BTW) it won't do remote to VMS.  It might
to Ultrix, eventually, but that's kind of vague, too.

So now the company that poineered interactive and remote computing is 
going to cut us off for lack of some connectivity.  3rd party DW 
terminals start about $2000 so I think we can safely assume a 
reasonable retail and justifiable transfer cost.  How many thousands 
of terminals do DEC employees have at home?  Has anyone thought of the 
impact of pinching off their effectiveness?  Multiply that by a couple 
of thousand to get the customer impact because most of them make 
extensive use of remote access, too.  The last customer I worked for 
had 2.1 terminals per employee!

Being but a cowboy from out West I don't know who to go visit and 
couldn't afford the airfare, anyway, but I hope some of you guys back 
there where decisions are made can make the powers that be aware of 
the potential disaster of the confluence of lots of DW interfaces and 
no remote access.

Sure, I'd like to see cct access to calendar, but I think it is 
short-sighted to put engineers to work on that today and not solve
the problem of tens or hundreds of applications coming down the pike 
which will also need remote access.  Remember, calendar is just a 
"teaser" and once the real product is out we'll probably all switch to 
it and be left high and dry again.  Imagine disconnecting all the 
incoming modems in all of DEC a few at a time....

RE: .-1
       >home. Also, the rumors I hear are that if DEC ever did develop a DW
>terminal (Program announced, BTW) it won't do remote to VMS.  It might
>to Ultrix, eventually, but that's kind of vague, too.
       
       	Don't go helping to spread a rumour like that.. It's not gonna do anyone
       any good. ESPECIALLY DECwindows product management when some poor
       tired sales specialist noting from home reads that and start a fuss for
       no reason the next morning..
       
       Also, there is no such thing as a 3rd party DW terminal. Just
       3rd party X-windows terminals.
       							mike

    As far as I know the DECwindows Terminal is _not_ programmed announced.
    
    Its "status" is that there are people in the field who are waiting for
    a newer set of PID materials to replace what we've been using so far...
    
    and there has been extensive discussion of DECwindows Terminal in the
    trade press as a consequence of discussions customers who have received
    PID's have had with the trade press...
    
    but as far as I know the DECwindows Terminal is _not_ programmed announced.

	re .32:

>    Re: .5   What's wrong with DWmail? Why can't I change the font to something
>I don't have to squint to read? 

	Because we had enough Mail-specific stuff to work on without trying
	to solve DECwindows-wide problems (particularly since we don't quite
	know how OSF/Motif will affect this).

>Why can't I read the next mail without having 
>to use the mouse?

	Because you didn't look at the pulldown menu for the accelerator
	(KP3).

	Mike

>    As far as I know the DECwindows Terminal is _not_ programmed announced.
    
They program announced it along with the announcements of the 2100, 
5400, 5800, 6000-400, 3100 servers, and NAS on the July 11 DVN 
broadcast.  I didn't stay around to watch the public announcement that 
followed half an hour later, but saw the other products in the local 
paper yesterday.

re -? on having a common interface-

While I agree in principle I think you underestimate the functionality
jump that DW allows in applications.  How can you do wysiwyg editing 
from character cells?  Or IC layout?  3D graphics?  I support the 
Cobol generator which is our first attempt using windows for case and, 
though it requires a graphics terminal, one time with a (VWS) 
windowing system and you'll never want to go back to the terminal.  It 
is a first generation windowing product.  Once it has matured there's 
no way you could do it all from a graphics terminal, much less a cct.

Some day soon systems design and implementation will be done graphically 
with network editors for navigation.  Sure, you could do a lot of what 
we do now with a line editor from an ASR-33, but who does?  Cct's will 
soon be obsolete for a lot of what we do.

The reason I'm beating this horse is that I'm supposed to support some 
of these new products and in the real world "they" never give us 
enough time at work and remote fills in a lot of necessary pieces.  It 
is a brave new world coming and I souldn't want to miss it, but I hate 
to go in handicapped!

I dont care to much about the character interface, but I believe that DEC and
all software developers for that matter have an obligation to publish 
specifications about file formats or structures whenever it provides a program
that uses such a file or structure to hold customer data.  Why?  Because the
DATA is customer property and the customer should be able to use and manipulate
his data anyway he sees fit.  If the provided software prevents the customer
from making some desired use of his property (i.e. the data) (as is claimed
by the gentleman who wants to access his calendar from home) then I believe
that the software provider is wrong if he does not provide a way that the
customer can roll his own.

This does not mean that DEC must support all or any manipulations on such 
datafiles (other than reading), but that customers must be able to
export or extract their data from such files without having to use the specific
program in question.

If DEC feels that a particular file format is important to be kept proprietary,
say for competitive reasons, then it should provide a set of library functions
that when used by the customer will allow it to access all of the data in the
file.

(Insert your favorite disclaimer here)

On remote access I've received assurance off-line that remote access 
for VMS with DWT is on the futures list.

RE: .37

    I wouldn't consider the small font on DWmail a DECwindows-wide problem. If
you allow the customer to change the font, it then becomes a customer problem.
At least that way, I could do it my way.

    And using KP3 inthe pull-down menu? Ha! I just looking in VAXmail and kp3
does something like DIR or DIR/9999. So, if you've defined kp3 to be "Next Mail"
then you've created a keyboard function that is new, and I wouldn't call that
"making things any easier". Ok, who out there uses KP3 for "Next mail". Who 
had never heard of KP3, and who misses the good ol' return key?

-Ken

In VMS Mail, Keypad "-" is "READ/NEW".  This doesn't do anything in
DECwindows Mail (perhaps it should).  However, Alt-R is defined as
an accelerator for this function in DECwindows Mail.

Personally, I find the MB2 popup the easiest to use for this.

			Steve

	re .42:

>    I wouldn't consider the small font on DWmail a DECwindows-wide problem. If
>you allow the customer to change the font, it then becomes a customer problem.
>At least that way, I could do it my way.

	The "small font" is a matter of taste. We did have SUE look at the
	font and some alternatives, and they suggested keeping the same font.
	Personally, I don't think the problem is the size of the font but
	the quality - I use the DECterm narrow font, which is actually smaller
	but which I find more readable.

	What is a DECwindows-wide problem is the problem of providing a good 
	user interface to customizing fonts. We requested the style guide 
	provide more guidelines on this for V2, and the toolkit provide a 
	standard font customization widget for V2, but neither happened.

>    And using KP3 inthe pull-down menu? Ha! I just looking in VAXmail and kp3
>does something like DIR or DIR/9999. So, if you've defined kp3 to be "Next Mail"
>then you've created a keyboard function that is new, and I wouldn't call that
>"making things any easier". Ok, who out there uses KP3 for "Next mail". Who 
>had never heard of KP3, and who misses the good ol' return key?

.43>In VMS Mail, Keypad "-" is "READ/NEW".  This doesn't do anything in
>DECwindows Mail (perhaps it should).  However, Alt-R is defined as
>an accelerator for this function in DECwindows Mail.

	The user interface is designed to integrate well with other
	DECwindows applications. VMSmail keypad keys are not supported -
	DECwindows-consistent accelerators are. The only DECwindows
	component with a function similar to Next Message is Notes, so
	we borrowed KP3 (also KP1 and Alt/U) from their DECwindows interface. 
	The Style Guide states that Alt/ accelerators are preferred, so that's
	what we used for functions (such as Read New Mail) which don't have
	standard DECwindows accelerators.

	Mike

Ok, Mike, I feel like this note (when we're not diverting somewhere) is now 
targeting at DWmail, and I never meant that to happen. It's quite clear to me
that DWmail had about the hardest time in creating a usable interface under DW
since it was required to be "usable" by both operating systems. This is pure
and simply tough to do. Overall, I think DWmail is promising, since there *are*
somethings it does well, such as multiple window reading, writing, etc. 
 
But if we get back to the original note, the topic is about customizing and that
is what I think DWmail misses. For example, if one could DEFINE 
(accelerator) KEYS, then I, for one, would be happy. The UCX FTP interface in
the latest field test provides TWO interfaces, the default which uses VMS-like
syntax and the /ULTRIX to provide UNIX-like commands. Nice. DECwrite allows one
to have four keypads, why can't DWMAIL? (Only two really needed) Do you see
what I'm saying. By the sheer fact that mail can handle DDIF files (AND VIEW 
them), DWmail is already better(in some ways) than regular ol' VAXmail. The 
thing now, is to focus on how the user interface can make people WANT to use it.

I was just reading the last issue of DIGITAL NEWS and they gave a nice write up
on the Calendar, but reported that some users have found the DWmail slow to
use and have reverted to using a DECterm for mail still. I've never thought that
DWmail is SLOW, just a pain to use. If only SOME key could give me the next
screens worth of mail, so I wouldn't have to use the mouse...

-Ken

	Yes, I'd like to see customization of accelerator keys too. And
	lots of other things. But I'm not a user-interface expert, I need
	guidance on how to do these things right. That guidance is lacking,
	despite attempts to solicit ideas. See my note on customization in
	CLT::XUI a few months back... It's not that we don't want to provide
	customization, but that when given limited resources and the choice
	between doing things that are clearly our own resposibility which
	we understand well, and doing things which need to be consistent
	across applications with no guidelines when we don't fully understand
	all the possible ramifications, the choice is not difficult to make.

	One of the things we have done, BTW, is improve performance...

	Mike