adf editAll vs. clickToEdit table performance - performance

If we have an editable table with two different approaches:
1. Click to edit - Table rendered as read-only initially and user clicks on row to edit.
2. Edit All - Table renders read-only initially and editable on click of an edit button.
Which one will perform better while also providing users with a simple edit feature.
Note that the number of rows is not significant. I am more concerned about the database trips, does edit all generate a lot of trips compared to clickToEdit?

Click to Edit tables perform better on the client side - this is the recommended approach of the two.
An even more recommended way is a read only table with a pop-up for editing a row.

Related

How to enable interactive grid cell validation in Oracle Apex Master-Detail page?

I have created a Master-Detail page in my Oracle APEX application. Basically i have a list of rows from one table and I can add values to it though a form. That works correctly, validations also work (every column from Master form can be accessed by adding ":" in front and that works in this case). I also have an option to edit click pencil icon in front of every row which lets me to update current row and also displays the Detail part of that row. Detail part is a list of values from another table that is connected to the first one using foreign key (Master-Detail: one to many). It is automatically displayed as interactive grid, so when editing my Master table value I can also add new rows to Detail table, but the validations don't work for Detail table. I tried accessing it's columns the same way as before, but it just doesn't work (tried to add PL/SQL expression validation:
:column >= 0
but that didn't work. How can I enable the validation for interactive grid, because I've looked into some resources about it, but they just show the first way, that doesn't work for me?
For a validation on an Interactive Grid you need to set the attribute "Editable Region" for the validation to your interactive grid. That works ok for me. I tried with a Master Detail on Dept (Master) and Emp (Detail) with a validation on detail of :SAL > 1000

WCAG - should a table (row) with dynamically populated data be included in the tab order?

For an app a table, that is dynamically populated with data, is important.
How should I do the tab order for tables of data? I searched for guidelines, but could not find a good one so far.
Possibilities I see are:
Only include the table itsef using a 'tabindex=0' attribute in the 'table' tag.
Include the table rows in the tab order with a 'tabindex=0' attribute in the 'tr' tag.
I guess using the arrow keys will allow for detail navigation.
What do you advice?
The table itself and the rows themselves are generally not keyboard focusable because they're not interactive elements. If the row was selectable or expandable, then maybe it could be focusable but it's usually an element in the table row (or more accurately, an element in a the table cell) that is selectable or expandable.
Without more details on the behavior you're trying to achieve, it's hard to give exact advice, but my initial thought is that none of the table elements proper (<table>, <tr>, <td>) should be focusable.
Regarding arrow keys for navigation, that's the pattern for a grid, which is a type of table that has editable cells (similar to a spreadsheet). Again, I don't have enough info on your situation to know if a grid is what you're trying to create.
For screen reader users, they already have a way to navigate to the table and navigate within the table using the screen reader shortcut keys, so don't worry about trying to make things focusable for screen reader users.
Lately I heard another suggestion from an expert.
Generally speaking, all interactive elements should be included in the tab index, such as buttons, form fields and links. If the entire table row can be clicked, this should be in the tab flow by means of a tab index 0.

Oracle Application Express empty edit page

I'm new to APEX. When I create pages in my app the edit pages that generate automatically work for some pages but not for others - they are blank except for the Create, Delete, Cancel buttons and the PK item (but that one's "Hidden"). There are no other items. I tried to add them manually but they don't connect to the respective rows - when I try to edit a row in the app it displays empty lines
Consequentially, I also can't delete any rows. I tried to compare everything in the settings of pages that have working edit pages but nothing worked
From my point of view, the simplest option is to create either
a form on a table with report whose wizard will create
an interactive report you'd use to view data; enable you to modify existing records using the "edit" icon at the beginning of each row; create new records using the Create button
a form used to modify and create new records
a tabular form (or an interactive grid) that enables you do do everything (insert, update delete) on the same page
If you create a form by yourself, you should create required processes which do different actions. I'm lazy to do it manually, so I always let the Wizard do the dirty job.
From your description, it seems that you created a form, included several items, possibly set them to be database items, but Apex doesn't know how to retrieve existing records (something like execute query in Oracle Forms). Therefore, try to use one of options I suggested and see how they behave.

Web App UX row selection best practice

Which is a better User Experience / Design decision for opening a table row (in a business website)? To place an "Open" button like this:
Or, to allow the row to be opened by clicking anywhere on it?
Your question assumes that people understand that there is more information to be gained by "expanding" these rows in this table. As this is designed right now, there are zero hints for a user that they are capable of viewing more information inside the same view that they are using.
Option 1: Open button
Let's assume (dangerously) that people are knowledgable that they can use this table to view more info about a line item in this table. The button itself is separated from the content it is referring to, breaking Fitt's Law. Also, the label is "open", which most users would interpret as taking them to another page, or opening a new context. "View More" or "Expand" would be a better label.
Option 2: Click anywhere
This is slightly better than the button, as it clearly relates the action to the content. However, it still doesn't solve the problem of exposing the functionality to the user.
I would recommend a combination of both of these approaches, making sure you are solving for Fitt's Law as well as exposing a label that will tell the users what functionality is present in these table rows, and how to access them.

front-end user interface to view record edit history

I have a web application that inserts/updates/deletes records from a database. Each time a transaction is made to a table, the change is recorded with the type of modification and the previous values from a trigger. What is a good web user interface layout to view such transactions to the users? Currently we just dump the whole history table to the user in a html table row and column format. I'm looking for some interface hints to present these edit history better.
Thanks for your input.
You can use a grid representation of the database table, plain html or produced by a js framework, plenty of options out there.
For the newly inserted records with no updates, just show the record with the insertion datetime.
For records that have been updated you can add a link/button at the end of the row with a title like "history" or "previous versions" or somethink like that and when a user clicks on it, then you can open a subgrid under this record or a pop up with a new grid (depends how you will implement your grid on the first place) which will show this record's history only.
The deleted records, you can add them (at the bottom of the table maybe) but grayed out or striked out. Again you can add the history option if you want it even for deleted records.
EDIT:
You could also add some filtering functionality above your grid for the user to select/see only the inserted/updated/deleted records and of course sorting functionality on the grid columns

Resources