Wish List

aware_support

6 items on the pureist's list above will be included.

Item no 7 - unlikely, but we'll investigate.

There will also be a new EXEC_SCRIPT action that will allow you to run Javascript from a process. Some of the functionality requested can be implemented using this action - close tabs, select tabs, close forms etc. Maybe we won't implement SELECT TAB but provide an equivalent Javascript that can be used in EXEC_SCRIPT.

BenHayat

aware_support wrote
6 items on the pureist's list above will be included.

Item no 7 - unlikely, but we'll investigate.

There will also be a new EXEC_SCRIPT action that will allow you to run Javascript from a process. Some of the functionality requested can be implemented using this action - close tabs, select tabs, close forms etc. Maybe we won't implement SELECT TAB but provide an equivalent Javascript that can be used in EXEC_SCRIPT.

Thank you Support for these nice feature. Please be sure we get documentation on how to use these features properly. Otherwise It would be a waste if we don't know how they are used.

Thank you again.

aware_support

And there will be no distinction whether a tab has been opened/closed by the user or a process - if a process is assigned to the tab it will be executed no matter how the form is opened/closed.

And confirmed - selecting a tab will be done by Javascript, not by a special action (in hindsight CLOSE TAB should have been done by Javascript as well, but it's already there...)

pureist

In devising:
"3. setting for the Frame, 'Run Process After Tab Closed (by User not 'CLOSE TAB' Acton)'"

I thought '..(by User not 'CLOSE TAB' Acton)' would likely be a requisite because if the closing was initiated via the CLOSE TAB Action, then there might be some conflict because before the CLOSE TAB Action has completed, the 'Run Process After Tab Closed' Frame Setting might be triggered as the tab closes.

Thus there might be 2 overlapping processes trying to run simultaneously, which could cause some kind of error.

But if they are queued so the CLOSE TAB Action fully completes before the Frame Setting to run a Process upon a Tab closing is triggered, then this new feature is even more flexible than envisioned, and allows rules/actions to be more logically organized and in one place. V. Good!

aware_support wrote
And there will be no distinction whether a tab has been opened/closed by the user or a process - if a process is assigned to the tab it will be executed no matter how the form is opened/closed.

And confirmed - selecting a tab will be done by Javascript, not by a special action (in hindsight CLOSE TAB should have been done by Javascript as well, but it's already there...)

aware_support

Upon further investigation:

"5. setting on Tab options dialog: 'don't switch to new tab [immediately following opening]"

This will not be done - too difficult to implement and very confusing to the user.

"setting on Tab options dialog: 'new tab opening position offset (+ or -) relative to current tab'"
There will only be an option to show at the end (like now) or immediately after the current tab

"3. setting for the Frame, 'Run Process After Tab Closed (by User not 'CLOSE TAB' Acton)'"
Any use cases for this item? Why would anyone ever want to start a process when a tab is closed?

pureist

Another suggestion to enhance the appeal of Aware to developers, new and existing:

Either via a Setting on the Frame or informing of the JavaScript (for use in forthcoming EXEC_SCRIPT Action), Initialization or render Script, make it possible to not display the tabs themselves of a Frame which is set to display Tabs, OR, make it possible to make the tabs row 0 px or 1 px in height, so it cannot be interacted with.

Tabs would still open as usual, and could be switched to and closed via the forthcoming enhancements.

This would achieve a big UX enhancement opportunity for configurers, because when there are more than 6 or 7 tabs open, and they have meaningful names, it is cumbersome for a user to scroll back and forth to switch between them.

The configurer could then have a query (whose records could be displayed horizontally AND over multiple rows, and be pageable) whose records are shortcuts to tabs open, and when clicked, select the tab or close the associated tab, by a process being started via AwareApp..

pureist

is not confusing for the user at all. If users were so useless, there would be a yes/no check box on a form which they can toggle so they can decide if they want to operate in "series or parallel", where 'series' is opening a record in a new tab and it it being switched to automatically, one at a time, and 'parallel' is first selecting all the records they want to look at (which then open as tabs), and then AFTER they have finished perusing the list of records, switching to the opened tabs in the order of priority they have determined.
is obvious. A Configurer wants to maintain a list of which tabs are open so they can prevent opening duplicate tabs of the same record. CLOSE TAB Action only covers a tab closing event initiated by itself. This application scenario has already been mentioned in the forum multiple times, by people other than me.

If it is very difficult to have a setting on the Frame to run a process when a tab is closed, then there is a work-around:

Add a setting to the Tab options dialog which makes it possible to prevent the X being on the tab, so the only way to close a tab is via a Close button or another button which runs CLOSE TAB, whose rules/actions can then deal with updating the list of tabs open.

aware_support wrote
Upon further investigation:
"5. setting on Tab options dialog: 'don't switch to new tab [immediately following opening]"
This will not be done - too difficult to implement and very confusing to the user.

"setting on Tab options dialog: 'new tab opening position offset (+ or -) relative to current tab'"
There will only be an option to show at the end (like now) or immediately after the current tab

"3. setting for the Frame, 'Run Process After Tab Closed (by User not 'CLOSE TAB' Acton)'"
Any use cases for this item? Why would anyone ever want to start a process when a tab is closed?

aware_support

3. is obvious. A Configurer wants to maintain a list of which tabs are open so they can prevent opening duplicate tabs of the same record.

This is a noble goal, but it has nothing to do with supporting a process when a tab is closed (try to describe a problem in the future, not your solution to the problem). The problem itself indeed has been raised before. A developer does not need to maintain this list - it should be done automatically if the developer chooses this setting when specifying properties of a new tab.

So the final list:

EXEC_SCRIPT command to run Javascript from a process. 3 scripts will be provided as examples
a) how to close a form or a query after a process is started from the form or query
b) how to select a particular static tab in a visual perspective
c) how to select a dynamic tab with a specified id in a visual perspective
Settings of a tab in a visual perspective will include the ability to start a process when the tab is activated
"New tab" settings to include:
a) Whether to open a new tab if the tab is already opened
b) Whether to show the new tab at the end or immediately after the current tab
Close operation for a form to include the ability to run a process after the form is closed[/b]

pureist

1. Considering Bruce's request to know which tab is Activated:
"2. Settings of a tab in a visual perspective will include the ability to start a process when the tab is activated"
you've used singular not plural and 'VP', so it's a bit ambiguous.

Does this mean it will be set on a per-tab basis ('tab in a VP' sounds like it), or it will be in the settings of the Frame and apply to all tabs, fixed and dynamic?
And if, per tab basis, then what about dynamic tabs opened during runtime, and knowing which one of them is Active? This is the main usage scenario for wanting to know which tab is active, I suspect.
Read here:
https://forum.awareim.com/d/8873/1&hilit=tab+has+focus#p39301
"I have a customer query and when the user selects a customer, it opens a NEW tab with the customer's orders. The user can do this again (and again) and now have 2 or more new tabs with orders for different customers. I have an option on the top menu to create new orders.."
..and here:
https://forum.awareim.com/d/8751/1&hilit=tab+has+focus#p38698

2. "3. "New tab" settings to include:"
a) Whether to open a new tab if the tab is already opened

Will the point of control for this functionality be the Instance ID?

If it is very difficult to have a setting on the Frame to run a process when a tab is closed, then there is a work-around:

Add a setting to the Tab options dialog which makes it possible to prevent the X being on the tab, so the only way to close a tab is via a Close button or another button which runs CLOSE TAB, whose rules/actions can then deal with updating the list of tabs open.

Thinking it thru further, an application might want to reopen the tabs which were open at the time the user logged off, thus maintaining a list of tabs open would be necessary.

BUT, probably the most important reason to be able to run a process when a tab is closed is because if the user closes the tab by clicking the X then there is no way of know which tab now has focus (refer 1. above), unless you have saved some kind of breadcrumb trail.
Running a process when a tab closes allows selecting of another tab and thus knowing which tab in in focus.

However, the work around 'Setting' above would circumvent this issue.

aware_support

For now we will implement process support for dynamic tabs only, which is where the most pressing need is. So the selection of a process will be not at the Tab level in a visual perspective level but at the New Tab Settings level when defining an output of an operation. At some point we may implement this support at a tab level in a VP, but not now.

Thus the new options for the "New Tab" settings when defining an operation will be:
a) Process name
b) Whether to always open a new tab (like now) or activate the existing tab if the tab has already been opened (Aware IM will be smart about detecting those automatically)
c) Whether to open the new tab at the end (like now) or immediately after the current tab

mrbdrm

aware_support wrote
So the final list:

EXEC_SCRIPT command to run Javascript from a process. 3 scripts will be provided as examples
a) how to close a form or a query after a process is started from the form or query
b) how to select a particular static tab in a visual perspective
c) how to select a dynamic tab with a specified id in a visual perspective

will we have the ability to pass BO value from the process to JS? like in custom query. (it's really important)
don't restrict the JS to tab functions please.

aware_support

will we have the ability to pass BO value from the process to JS?

Yes, you will be able to use tag expressions inside the Javascript that refer to objects in Context as usual

aware_support

We have just released build 2235 which has support for the features asked for in this thread (and some other improvements). This is the list:

Integration with Google,Outlook,iCloud,Exchange calendars through Cronofy
An option not to handle foreign keys when discovering attributes
EXEC_SCRIPT action
Ability to insert new tab after the current one
Ability to go to the existing tab rather than open a new one if a tab has already been opened
Ability to run a process when a dynamic tab is selected by the user
Ability to run a process when form is closed

BenHayat

aware_support wrote
We have just released build 2235 which has support for the features asked for in this thread (and some other improvements). This is the list:

Integration with Google,Outlook,iCloud,Exchange calendars through Cronofy

An option not to handle foreign keys when discovering attributes
3. EXEC_SCRIPT action

Ability to insert new tab after the current one

Ability to go to the existing tab rather than open a new one if a tab has already been opened

Ability to run a process when a dynamic tab is selected by the user

Ability to run a process when form is closed

[/b]

Awesome Support, a video will make these new feature clear as "Crystal". 🙂

pureist

when a tab is closed, and a dynamic tab automatically becomes the tab selected/in focus, will the process run?

aware_support wrote
6. Ability to run a process when a dynamic tab is selected by the user

aware_support

Yes

aware_support

We would appreciate if those who promised to contribute to this feature and didn't pay yet(and there were quite a few) pay Bruce asap. Otherwise, he will end up paying for a bunch of features some of which are not even relevant to him and are only relevant to those who promised to contribute!

It's only fair.

Thank you.

RLJB

I'm curious, can someone provide a use case (or two) of when this might be useful? How is it being applied in your app?

Ability to run a process when a dynamic tab is selected by the user
Ability to run a process when form is closed

Tks

customaware

What would be REALLY nice.....

A small sample with the build that demonstrated these new features, why you might want them and how to implement.

Nothing huge.... just a tickler.

pureist

Hang on a minute..
The only IP common/shared between Bruce's requirement and my proposed list of 7 enhancements to comprehensively control the Tab aspect of the UX, was knowing which tab is in focus (item 2. on my list from memory). The other 6 items were my IP.
None of us who had already cumulatively pledged $600 or $650 (without Bruce having pledged anything at that stage) asked Bruce to go off and commission (without informing us) the list of enhancements (we had pledged towards) directly without any consultation with other contributors.
None of us had any idea what was going on until Bruce's post after some days. We were all in the dark.
It was not a collaborative process.

People have to work. The working week is busy.
People need time to assess what was delivered against the list of enhancements they pledged their money towards, and then weigh any shortfall against any additional enhancements which were delivered, and determine what they feel is fair.
Obviously this requires installing the new build and pissing around for a while, which cannot necessarily be done in the hussle of the working week.
Posts like yours below can be interpreted/received by some people in a way that makes them feel pressured/obliged to contribute fully towards something which is different to what they pledged towards.
AND, that will only have the effect of ensuring that people DO NOT take a chance in future and pledge upfront towards future user sponsored enhancements.
Give it time. I'm sure people will do what they feel is fair.
And remember, $100 to you is easier to come by than for someone not in a Western country, for whom $100 is like $500 to you.

aware_support wrote
We would appreciate if those who promised to contribute to this feature and didn't pay yet(and there were quite a few) pay Bruce asap. Otherwise, he will end up paying for a bunch of features some of which are not even relevant to him and are only relevant to those who promised to contribute!
It's only fair.
Thank you.

« Previous Page