David, The other thing people can do, to get around the difficulty of larger complex dialog design, is to make much heavier use of menu items and submenus. Use them instead of radio buttons, and use them to launch other dialogs, and you can remove a lot of info from the screen; sometimes at the expense of an extra keystroke or two, but it's often worth it.
I realize my nested groups suggestions aren't easy to work with at first, so going in a completely different direction and using the menus may be better for many situations. Especially since you can add menu items on the fly, you can even create submenus which are constructed out of current data choices (you can see this done in the Immed program where the names of submenus are created as you add or edit snippets of code). I'm sure AI will eventually have time to review these XML dialog issues, but really, as compared to everyone else's needs, as long as we have work arounds I can understand why they're given low priorities.. Perhaps the Fusion product, which will have more of an interest and emphasis on visual appearance of things, will stimulate more interest in these problems. Chip Chip Orange Florida Public Service Commission Computer Systems Analyst 850-413-6314 -----Original Message----- From: David [mailto:[email protected]] Sent: Friday, April 01, 2016 11:24 PM To: Chip Orange; 'Window-Eyes Scripting List' Subject: Re: Small wish for the XML dialogs Thanks Chip, I am following your prctice - at least partially, when constructing my XMLs. I just wish there would be a way for me to control the dialogs to the higher extent. My guess is that this is one of the cases, where either people have never tried constructing anything more than a very simple XML dialog - and hence won't realize what we are talking. Or, they have at least enough sight to do their dialogs and check to see they are the way they intended them to be. Or, they simply don't care, long as things come out the right way for a speech-user. I don't know. But it is nice to hear, that at least one other blind person, finds himself struggling the same that I do. Your ideas, Chip, in their basic, are very helpful. The idea of nesting groups is what I am doing as well. A couple of your suggestions I have never tried, so will have to do some playing around here one of the days. And the idea of the mousing around, I have done for a long time. Only thing with the mousing is, that it takes quite a bit of time and efforts. Specially when things did not get totally where you wanted it. And you will all the time have to remember where on the screen your mouse is. That is why, for one reason, I thought it would be easier if I could simply tell the system exactly where I want things placed, and have that done. Just, for all of you, imagine if we were to save our files on our disks, the way we construct XMLs. OK, a bit out of scope that comparison, I know, but just for the samplification. You tell the computer to store your file under documents, and it does, but you don't know exactly which subfolder, or if it got the filename you hoped for. How much would you care, long as the computer was able to refind and load your file. But the day you want to know where the file actually is stored, or in any other way control it a bit more, you are bewildered. It is a seek-an-hide job, ain't it? Same with your XML elements. You tell the system to place them somewhere in a dialog, and don't really care, if all you want is to have the speech read out some controls in a given order, and let the user act upon them. But the day you, as a blind person, wants a professional and controlled layout of your app, you may hope for a way of controlling it somehow more down to the details. And you wish you could do so, without having to hunt around the screen, to check if any tiny change you make, really got correct. Well, I am not up for a prolonged arguing here, just aired a small wish. For those of you who - for whatever reason - don't care about the actual lookout of your dialogs, or who have never dealt with more complex dialogs with a number of controls; I guess you wonder what all of this hazzle ever is all about. And for those who have dealt with complex dialogs, and who happen to have a bit of sight, my suggestion could be for you to blindfold yourself for an hour, and sit down and construct just one dialog, holding say ten controls. Do all your posistioning, controlling and modification. Then get back to your result, when you again can see them with your eyes. Did you really get what you wanted? I am honestly eager to know. Because, IF you really got what you intended, then the XML system is really that reliable that i don't have to worry, and you could put me at ease. Or, maybe your blindfolded experience could lead you to some enhanced suggestions as to how a blind best can ensure his dialogs the best layout; and then you could enlighten both me and Chip. To be open-hearted with you, that would be of real value to us. Instead of just sweeping it all off the board, with some misunderstood comments, or sarcastic questions. Aaron, it is nice to hear that things were constructed with blind people in mind. I am sure you and the staff around you, have put loads of efforts into making this the best for us developers. Still, my question is, have you ever tried my above mentioned idea of doing the job blindfolded? Don't mean to be harsh, just wondered if you have. I have suggested similarly in other cases, when sighted people have "ideas" of how easy things have been made for blind people. In many cases, people may get a slightly different idea of what would be good and workable solutions. Or, they could at least more specifically relate to what the blind user find troublesome. Sometimes, you've just gotta experience things, before you can realize. :) All said in a friendly and smiley way. Had I been a newbie here, and simply just found things a bit confusing, I would maybe have been more at ease by the feedback in this thread. Yet, I have based my dialogs on some of the automated calculating built-in, and I have done extensive mousing. Through this mousing, I also have realized several times, that things did not really get positioned what I wanted them to. And, it is based on a few years experience - with a bit more than two controls in my dialogs - that I come back with this idea for improvement. Maybe the idea is not good in itself, the way it stands right now, but at least my hope was that it could be the foundation for some future way of enhancing the blind-friendly environment in which we already do our dialog-building. With a smile, at least now you know what a couple of us feel could be helpful. :) And thanks to all, for whatever constructive feedback you may have to give. I am still learning... :D o David On 4/1/2016 7:43 PM, Chip Orange wrote: > Hi David, > > Yes, I absolutely agree, this feature of WE (which is an absolutely great > feature (the XML dialogs)) does need a little more attention for exactly the > reasons you mention. To get around this, I use a lot of nested groups, > specify only the width of the outter most group using actual dialog units, > and use width and heights of either "group" or "fill". I have found this > gives the automatic dialog positioning algorithms the best chance of > generating postions and widths and heights that I'm the happiest with. > > I've found it's not actually the positions that are sometimes the most > problematic, but the widths and heights which the positions are then > generated from. > > So, to give you a rough idea of what I mean,I may want a column of buttons > down the left, next to an editbox, which I would like to fill all the space > remaining in my dialog. > I also add the window sizing option to the dialog, so that a user with a > bigger screen can "maximize" my dialog and see even more if he's sighted. > > I would then start out specifying the main dialog's width and height in > units; I don't like doing this, but without doing it, the automatic > positioning of WE is just far too often not usable. So, I may specify 800 > wide and 400 high. I would then check the position and the size of my window > using one of the developer tools which give you this information (TreeView > from AI, or Vic Beckley has written an app named Focused Window Detective, > which tells you about your currently focused window (such as the editbox) and > the parent window, in an easy to use way). I use these numbers and my > resolution of the moment (which I don't set too high so I can hope what I > generate will be something all users can run), to be sure the dialog I'm > generating is not too large. Later on as Tom said, I'll use the mouse to try > and verify that info is showing up for all controls. I'll adjust these > number as needed, somes as the last thing I do for the dialog. > > I'd make my main group horizontal, and I'd define two groups within it, both > vertical. I'd set the ChildAlign property of the main group to "top", so my > controls and any borders of my two vertical groups aligned at the top (don't > know if this is the most attractive, just what I prefer). > > I'll put my column of buttons in the left vertical group, and my editbox in > the right one. I won't define the width of the left vertical, because it's > just buttons, and I've found WE will generate a group just wide enough to > hold these buttons, which is just what I want. I'll probably set it's height > to be "group", so it will be the same height visually as the right vertical > group holding the editbox which is also going to have a height of "group" > (again, just a preference, but I do this when the buttons have some relation > to what's in the editbox). > > I usually give these groups a black frame (border), but again am not sure if > this is the most attractive or not. I use a lot of nested groups, and so > when you get down to a low enough level, I do stop giving them frames, and > instead set it to "none". I do always give a group of radio buttons a > visible frame. > > For the vertical group on the right (here's the important part), I'll set the > width to "fill", and the height to "group". Since I made this right vertical > group's parent be horizontal, then you can only use "fill" for the width of > its children. The height being "group" will have the same effect that I want > as "fill"; that is, if the user exercises the "maximize" choice, the outer > group will enlarge in both dimensions, and so the width of the right vertical > group will expand to fill any extra space in the outer group, and the height > of both vertical groups will expand to match the height of the outer group. > > I don't set the height or width of the buttons in the left group, but for the > editbox which I put in the right vertical group, I will set the height and > width to be "group" when it's the only control in its group (as it is in this > example), or I will set it's height to "fill" so it will take up as much of > the right vertical group as it can after room as been calculated for the > other controls in the group. Note again that since the editbox parent is a > vertical group, you can only use "fill" in the height of the editbox. The > rule is that you can only "fill" in the direction of the control placement > axis of the parent group. > > Later, I made decide that these buttons and their editbox are just one part > of a more complex dialog, so I'll just insert them as a unit into a dialog > which has other groups for the other controls I want to show. I do end up > with a lot of nested groups (take a look at the xml of the Remind Me Where > app, especially the dlg_GetDirections1 dialog), but this works for me when I > take a sort of modular approach in designing the dialog. You do have to keep > track of when you're using "fill" and "group" as widths or height, but it > ends up giving me the most possible room for editboxes and listboxes which > otherwise, can sometimes end up with a width or neight of 0 when WE > calculates it. > > Hth, > > Chip > > > > Chip Orange > Florida Public Service Commission > Computer Systems Analyst > 850-413-6314 > > > -----Original Message----- > From: Scripting > [mailto:[email protected]] On > Behalf Of David via Scripting > Sent: Thursday, March 31, 2016 9:35 AM > To: GWScripting > Subject: Small wish for the XML dialogs > > I have an idea, for an enhancement when constructing XML dialogs. That > is, if it is possible... :) > > When defining an element, you can set the hight, width and the X and Y > positions. Yet, for a blind person, with no sighted assistance, this is > really quite a hit-and-miss job. OK, we got the AUTO feature for Hight > and Width, and to play safe as can be, that might be the one way to go. > > But then we have the actual positioning of the element. Had all screens > looked the same, and all fonts been the same size, we could have gone by > screenpoints. But even that is a hit and miss. So, AISquared has > provided the chance to position our stuff on TOP, at BOTTOM, or align it > in the CENTER or near the LEFT and RIGHT edge. > > I just wondered, if it would have been possible to implement a chance > for me, to define the size of the element percent-wise, in both the X > and Y direction. I could then have decided that my button should sit in > the upper left corner, and take up say 10 X-percent, and 5 Y-Percent. My > Next element, an edit box, I could have defined to sit 15 percent down > the X-line, and cover the next 3 X-percent. that is, it would start at > X15, and end at X17 percent. And it would stretch from Y20 to Y49 percent. > > Hope the above gave a bit of meaning. The Dialog could then - all in the > background - do all the percent calculation, based on the actual size of > the dialog on the current computer, screen and under the currently > conditions that affects the dialog's physical size. It would have been a > bit easier, for me as a blind person to have things correctly positioned > and sized, did I have some tangible and reliable numbers to operate with. > > In other words, could we have a feature to set the actual upper-left and > lower-right corners of an element, and also the starting position for > it, all based on percents of the total dialog size? > > Anyone have some input on this? > > Thanks, > _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
