Patent Application
20250232109
A table, such as a database table, is a collection of related data that is held in tabular form. For example, the table may include columns and rows that overlap with one another to create an array of cells. Each row usually corresponds to a unique record and each column corresponds to a different field in that record. A software application may be used to fill-in data within the table based on data entered by a user. To enable data entry, the software application may output a user interface with input fields for inputting data via an input mechanism (e.g., keyboard, mouse, touch, voice, etc.) which is to be stored within the table.
For more complex data applications, the input fields are often spread across multiple different pages of the software application. As a result, the user often needs to navigate to multiple different pages in order to input the necessary data. The added time and inefficiency that is caused by having to navigate to the different pages is compounded when a user has to repeat the data entry process throughout the day.
Features and advantages of the example embodiments, and the manner in which the same are accomplished, will become more readily apparent with reference to the following detailed description while taken in conjunction with the accompanying drawings.
Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated or adjusted for clarity, illustration, and/or convenience.
In the following description, specific details are set forth in order to provide a thorough understanding of the various example embodiments. It should be appreciated that various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art should understand that embodiments may be practiced without the use of these specific details. In other instances, well-known structures and processes are not shown or described in order not to obscure the description with unnecessary detail. Thus, the present disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
Tables are database objects that store data in a predefined format which typically includes a plurality of rows arranged vertically and a plurality of columns arranged horizontally. The combination of rows and columns essentially creates a two-dimensional array of data values. When viewed as a whole, a database table can appear like a large block of numbers or other values which can be difficult to understand to a viewer. It can be even more difficult to view the table data when the user is on a device with a smaller viewing display screen such as a mobile phone, tablet, smart wearable device, or the like.
Software applications that enable viewers to visualize and enter data (e.g., into a database table, etc.) may often provide a series of workflows for entering data including multiple windows and/or display screens with different input fields for data entry. One of the difficulties of entering data into a table is when the data cannot be viewed on a single page. For example, when a user requests to add a new row to the table, but the display screen is full, the new row is often displayed on a different page. To access the different row, the user needs to navigate the display screen to the different page. This process may add a few seconds to the time needed by the user to input the data each time a new record is added to the table. When this process is repeated multiple time a day, such as for entering many data records, the additional time required to navigate to the different pages can result in significant delay and lost efficiency.
The example embodiments overcome the drawbacks noted above through a pop-up window that remains on the same page and enables the user to enter data into different pages of the user interface. The pop-up window is referred to herein as the “hidden row inserter”. The hidden row inserter may include a solid background. The software may overlay the hidden row inserter on top of the rows of data that are currently displayed on the user interface. In doing so, the user interface may partially conceal the underlying content enabling a clear view of the hidden row inserter. Multiple input fields and labels of the data to be entered into the multiple input fields may be displayed within the hidden row inserter. The labels identify the data that is to be input into the fields. The hidden row inserter may also include buttons or other user interface elements which enable a user to enter commands via the hidden row inserter such as to add a new row to the table, to close the hidden row inserter, and the like.
The hidden row inserter may provide a separate input area with respect to the user interface and may include one empty row which is a copy of an empty row from the original table. That is, the hidden row inserter (HRI) may be a table with one single row. The hidden row inserter may initially be hidden from view (e.g., not active) on the page. The hidden row inserter may be activated by different conditions. For example, the hidden row inserter may be activated by a user pressing a button or other control element within the user interface. As another example, the hidden row inserter may be activated automatically by the software in response to a condition such as the user interface being full and not having any more room for new rows of data. In this case, the software may detect that the user interface is full and automatically initiate a display of the hidden row inserter.
When the software initiates the display of the hidden row inserter, the software may render the hidden row inserter at a predetermined height within the user interface. The height may be fixed such that the hidden row inserter is always opened at this position regardless of whether there is content above the original table or not. For example, the position may be a particular row or pixel height. Therefore, it doesn't matter how much content is displayed above the table, the hidden row inserter may always be opened at this position. It should also be appreciated that the height at which the hidden row inserter is displayed may be adjusted by a user based on commands entered via the user interface and/or the hidden row inserter.
In this example, the user is entering data into data records 128 that are stored within a storage device such as a data store 126. The data store 126 may be a database, a cloud storage, a local storage, an in-memory storage, and the like. The data records 128 may be tables of data such as database tables, files such as XML files, JSON files, etc., documents such as word-based documents, digital documents, and the like.
During operation, the user may enter a command via the user interface 112 which identifies a particular record, search criteria to search for a record, or the like. In response, the command may be received by the software application 122 and used to build a query for querying the data store 126 for the requested record. In this example, the software application 122 may transfer the request to a query processor 124 which builds a query such as a structured query language (SQL) query, OQL query, XQuery, or the like, and submit the query to the data store 126. In response, the data store 126 may identify a correspond record, and return it to the software application 122 via the query processor 124. The software application 122 may display content stored in the record in tabular form via the user interface 112.
As an example, content from the data record may be displayed as a table on the user interface 112 containing one or more columns of data overlapped by one or more rows of data which are visually depicted on the user interface 112 in a comprehensible manner to a viewer. In this case, the user can activate a hidden row inserter from the user interface 112 as further described in the examples of
With the record displayed on the user interface 112 of the user device 110, the user can enter commands into the user interface 112 to modify the record by creating new data, reading existing data, updating existing data, deleting data, and the like. In this example, the software application 122 may execute program code to provide the query processor 124 with an identifier of a data record to be searched for, a keyword or term, a file name, etc. In response, the query processor 124 may identify one or more records and return them to the software application 122 where they can be accessed by the user via the user interface 112 displayed on the user device 110. The host platform 120 may provide services for executing applications. For example, the software application 122 may communicate with the query processor 124, the user device 110, and other systems and services using Hypertext Transfer Protocol (HTTP) requests.
The user interface 210a also includes a page count 227 that identifies the total number of pages of data rows on the user interface, and also a current page identifier 228 that identifies which page from among the total number of pages is currently being displayed by the user interface 210a. In this example, there is only one page of data. Therefore, the page count 227 and the current page identifier 228 are the same (i.e., 1).
According to various embodiments, the user interface 210a may have a limited amount of viewing space that can be displayed on the screen at the same time. The limitations may be the result of limitations on device screen size, limitations on server output, limitations on network bandwidth, and the like. In this example, the user interface 210a is limited to displaying eight rows of data at the same time. If a ninth row of data is added, the row will need to be added to a different page due to the limitations on the viewing space.
Referring now to
For example,
In this example, the software may receive the request for the new row 308 in response to the user pressing the add button 320. In response, the software may determine whether there is available space of the new row within the current view/page of the user interface 310a. Here, there is enough space and the new row 308 is displayed within the user interface 310a. Furthermore, a user can enter values within the new row 308 and press a submit button causing the content within the new row 308 to be stored/recorded in an underlying data record (e.g., table, etc.) with the data store. The user interface 310a also includes an identifier 317 of a number of rows within the user interface, and an identifier 318 of a total number of rows across all pages of the user interface. The total number of rows across all pages of the user interface will differ from the number of rows within the user interface when a second page of rows has been opened.
In this example, the row inserter window 330 includes an empty row 332 with a plurality of empty fields for receiving input alphanumeric content, text content, numerical content, symbols, and the like. The row inserter window 330 may be limited to only a single row being visible at once, however, embodiments are not limited thereto. The row inserter window 330 also includes a plurality of labels 333 that identify what data values go into each of the fields in the row inserter window 330. The labels are a copy of/the same as the labels in the user interface 310b. Thus, the user can easily visualize which column of data each input field corresponds to.
The row inserter window 330 also includes an add button 334 that the user can press to add a new record to the underlying user interface. The row inserter window 330 may be displayed at a predetermined row height within the user interface. For example, the row inserter window 330 may be displayed under the first row within the user interface 310c. However, the height is not limited to a particular height.
For example,
In some embodiments, the user may interact with the row inserter window 330. For example, a user may input commands on a user interface 310e as shown in a view 300E of
For example,
In the examples of
For example,
In 520, the method may include displaying a plurality of rows of data from a table among the tables of data stored within the memory via a user interface of a software application. The space that is available on the user interface may be limited. In 530, the method may further include receiving a request to add a row to the table. The request may be provided from the user interface. In 540, the method may include displaying a pop-up window via the user interface, the pop-up window comprising a plurality of fields for inputting data and an input button. In 550, the method may include receiving input content via the plurality of fields within the pop-up window. In 560, the method may include inserting a new row with the received input content into the plurality of rows of data displayed via the user interface, in response to a command via the user interface.
In some embodiments, the receiving may include receiving a request to add a new row to the table based on an input on the user interface, and the method may further include determining that the user interface is full in response to the input, and displaying the pop-up window via the user interface in response to the determination that the user interface is full. In some embodiments, the inserting comprises may include inserting the new row into a hidden page on the user interface in response to receiving a second command via the pop-up window, and further modifying a page number of total pages displayed on a currently shown page of the user interface.
In some embodiments, the method may further include determining that available space exists in the user interface, and the inserting comprises inserting the new row into a currently shown page of the user interface in response to the determination that the user interface has available space. In some embodiments, the receiving may include detecting a user input on the user interface with respect to a predetermined user interface control, and the displaying may include displaying the pop-up window via the user interface in response to the user input on the user interface.
In some embodiments, the displaying may include displaying the pop-up window at a height of a predetermined row of data from among the plurality of rows of data displayed within the user interface. In some embodiments, the inserting may include inserting the new row with the received input content into the table stored within the memory in response to the command. In some embodiments, the pop-up window may include a solid background, and the displaying may include overlaying the pop-up window on top of one or more rows of data displayed within the user interface. In this example, the solid background of the pop-up window my conceal underlying content within the user interface.
The network interface 610 may transmit and receive data over a network such as the Internet, a private network, a public network, an enterprise network, and the like. The network interface 610 may be a wireless interface, a wired interface, or a combination thereof. The processor 620 may include one or more processing devices each including one or more processing cores. In some examples, the processor 620 is a multicore processor or a plurality of multicore processors. Also, the processor 620 may be fixed or it may be reconfigurable. The input/output 630 may include an interface, a port, a cable, a bus, a board, a wire, and the like, for inputting and outputting data to and from the computing system 600. For example, data may be output to an embedded display of the computing system 600, an externally connected display, a display connected to the cloud, another device, and the like. The network interface 610, the input/output 630, the storage 640, or a combination thereof, may interact with applications executing on other devices.
The storage 640 is not limited to a particular storage device and may include any known memory device such as RAM, ROM, hard disk, and the like, and may or may not be included within a database system, a cloud environment, a web server, or the like. The storage 640 may store software modules or other instructions which can be executed by the processor 620 to perform the method shown in
As will be appreciated based on the foregoing specification, the above-described examples of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code, may be embodied or provided within one or more non transitory computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed examples of the disclosure. For example, the non-transitory computer-readable media may be, but is not limited to, a fixed drive, diskette, optical disk, magnetic tape, flash memory, external drive, semiconductor memory such as read-only memory (ROM), random-access memory (RAM), and/or any other non-transitory transmitting and/or receiving medium.
The computer programs (also referred to as programs, software, software applications, “apps”, or code) may include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, apparatus, cloud storage, internet of things, and/or device (e.g., magnetic discs, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The “machine-readable medium” and “computer-readable medium,” however, do not include transitory signals. The term “machine-readable signal” refers to any signal that may be used to provide machine instructions and/or any other kind of data to a programmable processor.
The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including simultaneous performance of at least some steps. Although the disclosure has been described in connection with specific examples, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the disclosure as set forth in the appended claims.
