As Product Manager for HTML Composer, and seeing all the postings on this facility, I would like to know what area of the tool do you believe is where you have problems. Is it Parameters and Chaining? Is it Controls? Please try to think about your experience and see if you can come up with a specific area, or areas that cause the most issues for you. I will then take this feedback and see what we can do to help make those areas better.

Thank you for your help in this matter.

One thing that has been problematic for me while using HTML Composer dealt with referencing external fexs.

I had three different fexs and six buttons (one button to run normally and another to run it deferred). When tying the last two buttons with the third fex it did not automatically include the request ids for any of the parameters. I did check and all of the parameters for the three fexs were exactly the same and had no defaults. Was a good learning experience to figure out what it is doing but that shouldn't happen should it?

The other thing (if it doesn't exist already) is a way to delete a tab order for a control. I usually go to the HTML to delete tab orders for labels but would be nice if there would be another way.

David,
three mayor issues ( among loads of annoyances )

One
We develop in a domain "development". When done all files ( html+fex ) are copied to the domain the users can access. When done, the HTML must be reassigned to the fex. Otherwise the internals are still refering ( domain & folder ) to the "development"-domain. Should be an easy fix.

Two
Artifacts, remnants, scrap left behind. E.g. Changing a input from static to dynamic will create junk in the code which you never get rid of. Best is always to start fresh, never update an HTML because of this.

Three
Moving the HTML elements (labels, iframe, spans, inputs, etc. ) around, lining them up ( even with grid and or align buttons ) takes a lot of time. When you have 10+ parameters, it's becoming a hassle. Working with TAB's is nearly impossible.

Greets,
Dave

Well, my most recent gripe turned out to be a bug that'll be fixed in the next hotfix, but there are a couple of other things in HTML Composer that I think could be improved.

One general remark to start off: Please try to prevent undoing our work! Sometimes people tediously crafted a form in a specific layout and then they need to add a few new controls for a few added parameters and BOOM! Gone is all the tedious positioning, all the smart table requests defined in embedded procedures, etc. Well okay, not _all_ of it, but it's still a pain. Francis recently showed a few nice examples of this behaviour.

Some things about checkbox controls:

1. Checkbox controls behave rather strangely by default. For starters, the first item is always checked, no matter what options you set.

2. Next to that, by default the checkboxes work like radio-buttons, where only one item can be selected at a time. If I wanted checkboxes to behave as radio buttons, I would have selected radio buttons instead.

3. There is no point in having an ALL option added to a list of checkboxes. It makes no sense. What does it even mean to have "ALL" checked and none of the other checkboxes? An "ALL"-checkbox would work as a META-checkbox that controls the check-marks in all the other checkboxes in the control.
That said, from a FOCUS point of view it makes sense to send a FOC_NONE if 'ALL' options are checked (although semantically that is a bit contradictory) instead of a (potentially) humongous list of options.

4. If you create a checkbox, the default height of each item is something like 75 pixels. Why? What's wrong with 'auto' (in CSS terminology)? I don't think the current height is what people would want by default, which means that every time any of us add a checkbox control, we need to change the height.

5. By default, new controls seem to get the "required" flag. Please turn that off by default. It's great that we can specify that a field is required, but let us decide when please.


Chaining... Yes, that can definitely use some improvement:

1. It seems impossible to create a listbox control of which the content is filtered by multiple preceding controls. One preceding control? That works alright. With multiple, you're supposed to add new conditions. I can't figure out how;

• The interface for such bindings is totally confusing; it lists every condition on each binding. Which one applies?
  
• The constraints that the 'extra' controls should apply to the final listbox don't seem to be applied, or the chaining stops working altogether.

2. When modifying an item in a chain, for example by changing the type of control, the chaining definitions are thrown out. Yet, as Dave already mentioned, part of the definition seems to be remembered and it's impossible to get right once that happens. Controls in this situation are unbelievably stubborn. Plus, you just undid some of our work that may have involved a complicated definition.


Some things about the generated HTML:

1. Many of us prefer to work with the underlying code. The way that the HTML composer bindings are set up in the resulting HTML page is:

• unreadable; the lines in the XML control definitions are too long and the indenting that was apparently intended to be there is broken because after the indenting tabs there is a newline.
  
• very hard to hand-edit; references are all over the place. There are ibi-internal id's and HTML id's. There are multiple sections in the XML that reference one another. It all looks like it could be simplified a bit. In fact, that's the first thing I did when I wrote my own implementation.

2. In that same vein; the generated HTML input elements are written with their style-information at the front, and the important information (such as name and id attributes) at the end. If you're looking for a HTML form element in the source, you have to drag the horizontal scrollbar until you find the attributes you're looking for. Seems a bit unnecessary.

3. This is new in WF77; When adding new form controls, there are a couple of bounding boxes around the controls. We don't want those. What we do to get rid of them is to alt-drag the controls from inside those boxes to there final location on the page, and then we delete those bounding boxes. We have to do that every time we create a form or add parameters to an existing one.

4. When you add extra parameters to a fex and "update" the submit button, the controls are placed where the button used to be and the button that you carefully positioned the previous time is shifted down. Francis described this rather well recently, including screenshots.


Embedded procedures:

Those are just too limited as they are. The feature can handle a simple TABLE-request with two fields as they are in the accompanying master, but as soon as you start modifying the generated TABLE FILE definition to include, for example, a DEFINE or COMPUTE field, or when you decide to request the data ordered alphabetically instead of by ID (after all, why sort the data twice?), stuff breaks.
Often, the control containing the request at least seems to still function, but any chaining to or from it just stopped working, which isn't immediately obvious either.

We should probably be using external procedures for these cases instead of embedded ones, but the way you get to define embedded procedures in the UI suggests that you can edit them too.


Date controls:

It may be us, but the "correct" date formats never seem to be in the dropdown where you select them. In fact, we'd much rather be able to type what we need, for example: DD-MM-YYYY. This date format doesn't necessarily match our masters. There is a difference between date-formats in the database (and in masters) and date-formats used in user interfaces, the control doesn't appear to account for that...


I'm probably forgetting a few things, but that's quite a long list already.

@Wep5622

Generated HTML item 3.
Besides not being able to turn of the generation of a bounding box.
It -is- possible to just click it and choose "delete container" only.

Groeten,
Dave

David,

I don't seem to suffer from the same issues that others are suggesting here. That may be because I don't develop interfaces as complicated as the others on this forum.

My biggest area of concern has to do with multi-language support, especially for labels. Currently I either have to develop 2 or more interfaces, or use an init process to replace the labels on load. It would be a huge time saver for me if I could insert multiple label values at developer time that will be automatically renders based on the user's language setting.

Regards

Many good points made above. Here's an additional minor one that comes to mind: Only input elements should be set as tab stops. Users don't want to have to tab to every invisible element on the page!

For me, one of the biggest issues is the way that the HTML Composer reworks the whole page any time a page is opened. One often cannot make a simple change without drastic consequences.

Thanks,
Rob

David,

Thank you for this gracious request. I hope there is no deadline as my list is long, and I would like to spend time on preparing an organized list.

Regards,

Francis.

Dave,

Regarding your post:

Item 1 - Usually when sites have dev, test and prod environments and plan to move things between them, they keep the exact same domains, folders, etc. so that they can move items without having to worry about their internal references. It would appear that yours is not an exact copy and that is why you need to relink your external items.

Item 2 - we will look into better garbage collection.

Item 3 - use a forms and containers could help in this. Based on similar facilities, like Microsoft Visual Studio, this is a common issue.

@David

Thanks for your replies. I will elaborate once. No need to go in discussion here.

Item 1
Yeah, I know. But we don't have that. Firstly because having a complete seperate develop/test enviroment will cost us another full-license.
Please don't play down our issue just because we don't stick to your program.
It's such a minor thing to fix. Simple find/replace. I'm considering writing a .vbs to do it for me.

Item 3
Yes, forms and containers help.
But no offence.. ...but please don't compare MS Visual Studio smooth & fast interface with this WYSIWYG HTML editor ( that runs on IE-engine ). E.g. try to select multiple controls with Ctrl, see how much time that takes.


By the way,
great to be asking this in the first place, I hope it will help to improve the tool.


Greets,
Dave

If it's helpful to the discussion, here's some info on how these affect us:

Item 1 - We have the same issue. We have a single production environment, so we do development in one domain and move the completed reports into production domains which requires updating all the connections. This could be approached a number of ways; I now use Javascript to do the work for me.

Item 3 - Our users also find that this feature could be improved. Other editors that I've used have features such as horizontal and vertical align, snap to grid, or nudge. I personally haven't dealt with this in a while as I now use CSS with auto spacing and containers.

Thanks,
Rob

I suspect that I am going to start a firestorm here, but, I just have to throw my two cents in.

I have just finished an application for my latest client. Total elapsed time from first design meeting to production - 2 months. Application designer, and coder for the launch page and all reports and graphs - me.

One launch page that contains:
19 tabs
25 report frames which display graphs, and each graph has a detail drill down associated with it.
50 buttons - Each causes a different graph to appear in either one or two report frames depending on which tab the button is on.
9 list boxes bound to parameters, some of which are chained, some are not. 5 are data driven dynamic lists, the others are static.
3 hidden edit boxes also bound to FOCUS parameters, populated via JavaScript when the user clicks on a tab or a button.

This client is also using one environment, so development and Production are in two separate domains.

I built the whole thing with the Composer. AT NO TIME did I thnk I was smarter than the tool for creating the HTML. And before you care to comment about my HTML skills look at www.tara-solutions.com or www.rbcsportzone.com. Both are my companies, and I do all the web master work on both of them.

I did write a fair amount of javascript to control the look and feel for the user's experience.

I did 'adjust' the XML when necessary to ensure proper performance.

When I moved all of this to their 'Production Domain', the first thing I did was to create a folder that had the EXACT same properties as the development folder. Then I opened the launch page in the text editor rather than composer, and low and behold, search and replace of the value for IBIMR_domain in all request id's, and the app was up and running in production. 10 minutes for that 'promotion'.

As I contemplate whether I will ever go on the road to do WebFOCUS again, now that I have seen age 65 come and go, it is my conclusion that as soon as I learned to use the tool the way it works, rather than trying to make it work the way I want to use it, I got much more productive. That's just my experience, and my two cents

Everyone - this is a fantastic discussion!

I have a question for the moderator...
Is there a way to keep only ONE thread for the collection of issues and then branch out the discussion of each issue in separate threads? My fear is that we'll go down a single path getting caught up in the details of one specific thing and miss the bigger objective which is to improve the HTML Composer tool.

If I understand correctly, David Glick's objective is not to solve all the iussues here in the forum but it is to create a prioritized list to work from. Please correct me if I'm wrong David.

Keep the suggestions coming. Let's work together to make HTML Composer the best tool it can be

Regards,

Dan

Thanks David for starting up this topic string and thanks for everyone's input.

Dan, right now there is no built-in way to monitor and keep all related posts together. What I would suggest is that, we can treat this one as the "master" list, and for any questions/issues/techniques that need additional detailed investigations, it can be started as a new topic, with a URL listed in this master lt as reference. Please feel free to make any suggestions.

To all, keep all those good suggestions/comments/questions coming in please!!

Cheers,

Kerry

An additional note to all:

As always, everyone should continue to log any problems or questions with Customer Support Services, who will dispatch your issues quickly. Logging the cases allows us to track and escalate problems in an orderly manner.

Cheers,

Kerry

Dan is correct in that I am making a list and not solving points raised unless I can.

A lot of the posters have already described my biggest issues. I would agree with almost all of what Wep5622 pointed out; I would strongly agree with some of the following as well:
- default required to NO
- only input elements (and buttons) should be tabbed, not text labels
I would think these would be easy changes/fixes.

lots of problems with Parameters and chaining:
I find that chaining works, but could work a lot better. It just seems to be quirky depending on how complicated the chaining needs are. I've had a lot of trouble adding new parameters after a form is initially built, ie they won't pull in and I have to basically start from scratch, they'll mess up existing parameters/layout and I have to start from scratch. It looks to me like I should be able to manually create/link on the params tab, but I have never been able to this successfully so I guess if that functionality worked (or worked better/easier to figure out) that would help a lot. The quirkiness around parameters is probably my most frequent irritation with the tool.

I've also noticed problems with the way it cleans up the code on controls once they are deleted- I think someone further up mentioned. I've also noticed that the code doesn't clean up well if you add an event and then want to remove it; I usually have to manually clean up the code in the HTML tab to really remove it.

A nice enhancement would be to default the value for date prompts to things like Begin/End Month/Week etc. I've written javascript to do this and it works fine, but it would be easier to implement and maintain if it were available on the calendar control itself.

Tree Controls are my main concern at this point. Making them Multi-select a little bit easier.

When I link my report fex to my HTML, I lose the multi-select on my tree controls. I have break the associated parameter with the tree control, then re-create it, then link it back to the control, then I have to go into the HTML and insert in the associated request id in order for the tree control the pass the values into the report fex.

Not necessarily related to HTML Composer, but the Saved Parameters with the Tree Control do not work correctly.

Crymsyn,
Based on your description, I recreated your scenario with three fexes and six buttons. All six buttons worked for me. My steps are as follows:
1. Create three different reports with the same parameter.
2. Insert six push buttons on the HTML canvas: Run1, Defer1; Run2, Defer2; Run3, Defer3.
3. Create a hyperlink on the first button, Run1, that would execute report1.
4. Create a hyperlink on the second button, Defer1, that would run report1 deferred.
5. Follow the same technique for the second and third sets of buttons to execute reports2 and 3 in a similar manner.
When the page is rendered, each button works.
Please let me know if your steps are different.

Also, any object can be removed from the tab order by giving it a Tab index of -1 in the Properties panel.

Lisa,

It is easy to explain what should happen and it is easy to create a demo to prove what is supposed to happen does indeed happen. What is not easy is to explain why in the real world something does not work. This is where looking at the code (forbidden, I know...) comes in handy, it seems this is the only way to verify that the variable request ids are applied for each request on the page.

Also, can someone explain why a tabindex property is added to every element on a page, including labels, spans, tab control, tab, tab body, etc. In the real world, as a page evolves, the tabindex becomes completely useless, as controls on the page are not necessarily added in the correct order. It would be nicer if tabindex was a property that was off by default - it should be up to the developer to add them.

Francis,

tab index is needed for section 508 readers.

Also, Lisa is asking for information to further assist. If it is not provided, we cannot help the user.

Everyone,

It seems that the majority of this thread deals with the Parameters area. If we were to show the populated values when the user is on the Parameters tab, and if the user makes a bad change, the values would go blank, or show what they do not want, would that be helpful?

David, this does not answer your last question, which I'm not sure I understand - the "user" - is that the developer or the end client?

From a developer's perspective, I think it would be very helpful if we could design a parameter screen WITHOUT first developing a report and have it's -DEFAULTs and WHERE statements and BY statements and Measures structured for the parameter screen. I'd like to build a parameter screen, add controls, connect them to variables - all without caring how the report is coded.

David, I don't really see what adding populated values would add to the parameters screen. Running the HTML page in a browser results in the same thing and the same amount of frustration.

IMO, the real issue with the parameters screen is that changes that people expect to be perfectly valid are considered a "bad" change by the tool and tend to break things in a way that can't seem to be repaired once it's broken.
It seems to me as the tool comes across as fragile, while it's not really powerful enough to handle everything people want it to handle - which in turn results in broken controls and adds to the sense of fragility of the tool.

With regards to the tab indices; they may be needed for section 508 readers, but if their indices have no relation to what is on the screen then they'll just cause confusion for the target audience instead of helping them.
Adding those indices automatically may be nice in theory, but in practice to be compliant you need form designers (people) who know how to design a form such that it complies to section 508. I'm sure that such designers rather add the required indices themselves where they are needed instead of getting them added automatically in some seemingly random order and having to hunt them down and correct them manually.
Expecting us mere mortals to do the same is rather... utopian, I think.

Francis,

"user" means the user of the HTML Composer. The best practice and premise for the intial creation of HTML Composer is to create the Reports and Charts with their parameters in use and then reference or import them into an HTML Composer page so that we detect the parameters and create the controls for them. Creating parameters and controls first poses issues in that nothing is guiding the creator of the page and they can enter a misspelled parameter name, or a control that is multiselect for a single-select parameter, etc. However, the ability to create parameters first and attach report after has been asked by one other person. You can actually do this today by create parameters on the Parameter tab and then controls, binding them, and then attaching a report that uses those same parameter names. We are considering making it a lot easier by having the "New Parameters" dialog come up on switch from Parameters tab to Design tab so that controls, and chaining may be accomplished through use of that dialog.

I have created a parameter and then bound it to a control. It didn't get passed to the report. I feel I shouldn't have to reattach to the report every time I add a parameter. In fact, it appears I have to re-attach three times every time I add a paramter - once for the Run button, once for the Run Deferred button and once for the Schedule button.

And I don't want every -DEFAULT variable brought into the HTML page just because I re-attach the fex. Yes, I know I can use -DEFAULTH, but I don't think HTML Composer should bring these in without asking.



In this particular case, these variables are used in an included error-checking program - they're not part of the report code at all.

Wep,

We believe by showing the population at design time, the designer will see a problem occur immediately. They will not have to run the page to see it. We are also thinking of popup messages when something is done that affects something else, for example, the designer modifies the default population request, so now any chained controls need to have their population inspected to make sure it is still valid.

For tab index, we are going to make the automatic creation optional. It will be on by default since we need to maintain current behavior, but it can be turned off.

Francis,

If a report uses the exact same named parameter as on a page, it should be used by the report. When you add a report to a page that has the same named parameters already, the New Parameters dialog does not display since we know the parameters already exist on the page. We also add that report name to the run button automatically. So, I do not see why you need to manually add it, unless this was an ability we added in a later release. I'll have to look into that.

For -DEFAULT, each person has their own lokes and dislikes. Most want these added. I suppose we can make it an option.

I don't want to have to reattach the fex every time a new parameter is added.

The model as designed is great for build-once-and-never-touch-again, not for a constantly changing real-world environment.

Fragility is a good term. I shy away from using this tool because it breaks things for me almost as often as it helps. When it breaks I basically have to start over. Whether this is due to my ignorance or the tool itself becomes irrelevent. I don't want to go back to square one.