Patent Application
20130162670
This description relates to a dynamic card view.
A large collection of objects (e.g., objects in a table or database) may present various challenges. For example, it may be challenging to maintain and display the large collection of objects in a desired manner and/or format. Also, current table-related features may make it possible to display only one primary object in a row, whereas this may not be sufficient to meet current display and view needs. Thus, it may be desirable to have systems and techniques that provide flexibility in displaying and viewing objects from a table or database.
According to one general aspect, a computer system includes at least one processor and a non-transitory computer-readable storage medium that includes instructions executable by the at least one processor. The instructions are configured to implement a table having a linear collection of multiple primary objects, where each of the primary objects occupies a single row in the table and a table control module configured to create virtual intermediate row-level objects from the linear collection of multiple primary objects. The virtual intermediate row-level objects include a first subset of the primary objects linked to one or more other subsets of the primary objects in a virtual hierarchy using a binding mechanism, where the first subset of primary objects is different from the other subsets of primary objects. The instructions are configured to implement a card view module configured to generate a card view from the virtual intermediate row-level objects and to render a display of the card view having multiple cards in a single row, where each of the cards represents one of the multiple primary objects.
In another general aspect, a non-transitory computer-readable storage medium stores instructions that when executed cause a processor to perform a process. The instructions include instructions to create virtual intermediate row-level objects from a table having a linear collection of multiple primary objects, where each of the primary objects occupies a single row in the table. The virtual intermediate row-level objects include a first subset of the primary objects linked to one or more other subsets of the primary objects in a virtual hierarchy using a binding mechanism, where the first subset of primary objects is different from the other subsets of primary objects. The instructions include instructions to generate a card view from the virtual intermediate row-level objects and to render a display of the card view having multiple cards in a single row, where each of the cards represents one of the multiple primary objects.
In another general aspect, a method includes executing instructions recorded on a non-transitory computer-readable storage media using at least one processor. The method includes creating virtual intermediate row-level objects from a table having a linear collection of multiple primary objects, where each of the primary objects occupies a single row in the table. The virtual intermediate row-level objects include a first subset of the primary objects linked to one or more other subsets of the primary objects in a virtual hierarchy using a binding mechanism, where the first subset of primary objects is different from the other subsets of primary objects. The method includes generating a card view from the virtual intermediate row-level objects and rendering a display of the card view having multiple cards in a single row, where each of the cards represents one of the multiple primary objects.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
Referring to
The table 102 may include many objects. In one exemplary implementation, the table 102 may include thousands, tens of thousands, hundreds of thousands or more objects. The objects in the table 102 may represent any type of data or data list (e.g., business data, supply chain data, customer relationship data, human resources data. Also, for example, the objects may be a list of reports (e.g., expense reports), forms into which data may be input, pictures, other lists of data, maps, images or any other type of object.
In one exemplary implementation, the collection or list of objects may be related to each other. For example, the objects may be related by the type and/or the format of the object. The objects may includes one or more fields that are common to each other.
Referring also to
Referring back to
The card view is a defined view of the object as a card. Each object in the table 102 of objects may have its own card view. The card view is a flexible display format that may be designed and arranged in a configurable format. The card view may be designed in a format that is desired to display each instance in the collection of objects from the table. In one exemplary implementation, the card view may be a read-only view, where the card is for display only and no actions may be performed on the card.
In other exemplary implementations, the card view may be editable. For instance, the card view may includes actions that may be performed on the particular object through input by a user. For instance, the card view may be a form that may be edited through input by a user. The form may include input fields, drop down menus and other actions, including options to submit and/or to save the information. In one exemplary implementation, only the data that is input into the card may be communicated to a backend application such as, for example, application 104.
In some exemplary implementations, the application 104 may be, for example, a financial application, a business process application, a human resources application, an engineering application, a customer relations management application, a supply chain management application, and/or any other type of application. In some exemplary implementations, the application 104 may be an enterprise application or a suite of applications.
A card in a card view may be a modelled pane (e.g., a form pane) or a custom UI or a combination of a modelled pane and a custom UI. The card in the card view may be user-configurable meaning, for example, that a UI designer may model and pre-define the format and the layout using a pane modeller module 105. The pane modeller module 105 may include an application that allows for the modelling and design of the card view. While illustrated as part of the system 100, the pane modeller module 105 may be implemented as part of other systems that are specifically meant for the design and modelling of user interfaces, including cards in a card view.
The system 100 includes a table control module 106 and a card view module 108. The table control module 106 and the card view module 108 may work together in a coordinated manner to render a display of a card view of objects in table 102 in a viewable window 110 on a display 112 for a user 114. Although the table control module 106 and the card view module 108 are illustrated in the exemplary block diagram as separate modules, the table control module 106 and the card view module 108 may be implemented a single module.
The table control module 106 is operably connected to the table 102. The table control module 106 is configured to create virtual intermediate row-level objects from the linear collection of objects in the table 102. The table control module 106 may create the virtual intermediate row-level objects by creating subsets of the primary objects that are bound to each other in a virtual hierarchy using at least one binding mechanism. In this manner, the table control module 106 may have a first subset of primary objects that are in a first column. The table control module 106 may bind other subsets of the objects to the first subset of objects in subsequent columns (e.g., a second column, a third column, etc.) such that multiple objects may be generated and rendered in a same row of a card view. The table control module 106 is configured to transform the linear collection of objects into a multi-dimensional virtual format that enables a display of multiple objects as a card view in a single row, where each of the cards in the card view represents an object.
The card view module 108 may generate a card view of the objects from the virtual intermediate row-level objects and the subsets of objects that are virtually bound to one another. The card view module 108 may render a display of the card view having multiple cards in a single row. In one exemplary implementation, the display of the card view may be rendered in a viewable window 110 on a display 112. The display 112 may be operable coupled to the system 100. In other exemplary implementations, the viewable window 110 on the display 112 may be implemented on a computing device that is in communication with the system 100 over a network (e.g., a wired or wireless network) including a local area network (LAN) and/or a wide area network (WAN) such as the Internet.
The table control module 106 and/or the card view module 108 may receive inputs from the display 112 as to the current size of the viewable window 110. The number of cards that are rendered for display may be based on the size of the viewable window 110 and/or the size of the card for each object. As the size of the viewable window 110 dynamically changes (e.g., the user changes the size of the viewable window 110), the number of cards rendered for display in a same row changes dynamically. In this manner, the resizing of the viewable window 110 may dynamically cause a number of cards displayed in a single row to change.
In one exemplary implementation, the table control module 106 may determine the number of cards to fit in a row based on a size of the card and a size of the viewable window 110. For example, the table control module may use that size information to determine the number of cards per row and then divide the number of objects in the table 102 by the number of cards (or objects) per row to create the virtual intermediate row-level objects. The number of objects per row are each a subset of the total objects in the table 102. The first column of objects in the virtual intermediate row-level objects is a first subset of the objects and any subsequent columns are other subsets of the objects that are bound to the first subset of objects by a binding mechanism.
In one exemplary implementation, the table control module 106 may perform or use a binding expression calculation service. This service may automatically check for the parent context and if the control is being hosted in a card view, it calculates the binding expression such that the card view may be generated by the card view module 108. In one implementation, the calculated binding expression may be: CardColumn[n].DataObject<FieldName>, where the CardColumn refers to a subset of the objects for the row, n is the index of the card in the row and FieldName is an actual data field from the object.
In one exemplary implementation, the table control module 106 performs functions related to paging. For example, if the table request data for row n, then the request is transformed for object with index n*c and n*c+1 in the original collection, where c is the number of cards per row.
Referring to
The table control module 106 divides the objects by the number of cards per row and creates a first subset of the objects 203a, 203c, 203e and 203n and links a second subset of the objects 203b, 203d, 203f and 203n+1 to the first subset of objects to create a virtual hierarchy using a binding mechanism. The table 350 is not itself made visually available for display.
Instead, the card view module 108 generates a card view of the cards from the table 350 and displays two cards per row in the viewable window 110, where each of the cards represents one of the objects. The entire columns of cards may not fit in the viewable window 110 at a same time and may only be displayed as a user scrolls or moves in the viewable window. In one exemplary implementation, the card view module 108 is configured to generate the card view and render the display of the card view of only the cards capable of being displayed in the viewable window 110. In this manner, processing power and time are saved because only the cards that will be visually displayed need to be created and rendered for display. The card view module 108 dynamically creates and renders the card view based on input received through the viewable window 110. In this manner, as a user 114 scrolls through the rows of multiple cards, the card view module 108 creates and renders the card view just for those cards that will be visually displayed.
In one exemplary implementation, the binding mechanism used to virtually bind one subset of objects to another subset of objects in a row may be an attribute or field or other criteria that is common to each of the objects. More than one binding mechanism may be used.
Referring to
As discussed above, each of the cards in the second column 470b, 470d, and 470f is linked to one of the cards in the first column 470a, 470c, and 470e, respectively, using a binding mechanism. In this example, the binding mechanism may be one of the fields in the report or an index field or an identifier field. The binding mechanism may or may not be displayed on the cards. In one example, the binding mechanism may be a hidden attribute that is common to each of the cards.
A selection of one of the cards (e.g., a selection of one of the reports) 470a-470f may provide access to additional or other information related to the report. For example, a selection of one of the cards of one of the reports may cause another window to open, where the other window includes additional or other information related to the selected card view.
In this example, other actions may be performed on each of the cards 470a-470f. For instance, each of the cards 470a-470f may be expanded and/or collapsed. Alternatively, an expansion or collapse of one of the cards in a same row, such as a selection of card 470a, may cause both cards in the same row 470a and 470b to both expand or collapse.
The number of cards displayed in a row in the viewable window 410 may be based on a size of the viewable window and a size of the cards. For example, if the viewable window 410 is made smaller by input from a user, then the card view may dynamically change to a single card per row. As discussed above, the card view module 108 may generate and render the card view in real time or substantially real time for only the cards to be displayed in the viewable window 410. When the viewable window 410 is resized, the card view module 108 re-generate and re-render the card view to display cards per row that will fit in the re-sized viewable window.
In one exemplary implementation, one of the cards 470a-470f that is in focus in the viewable window 410 may be an anchor object. The anchor object may be the primary object (e.g., an object in the first column of displayed cards) of a currently selected visible card. When the card view structure is changed, for example when the viewable window is resized, the card view brings the anchor object and its row of cards, which may be referred to as an anchor row, into the viewable window. In this manner, the user context and the focus does not change and remains consistent when the card view structure is changed.
Referring to
In this example, each object and displayed card is an editable expense form, where each of the forms may be edited. A user may input values or select options from the different fields in the expense form. All of the fields and layout of the card may have been pre-defined by a designer through the pane modeller module 105 of
The number of cards displayed in a row in the viewable window 510 may be based on a size of the viewable window and a size of the cards. For example, if the viewable window 510 is made larger by input from a user, then the card view may dynamically change to multiple cards per row. As discussed above, the card view module 108 may generate and render the card view in real time or substantially real time for only the cards to be displayed in the viewable window 510. When the viewable window 510 is resized, the card view module 108 re-generate and re-render the card view to display cards per row that will fit in the re-sized viewable window 510.
Also, in one exemplary implementation, one of the cards 570a-570d that is in focus in the viewable window 510 may be an anchor object. The anchor object may be the primary object (e.g., an object in the first column of displayed cards) of a currently selected visible card. When the card view structure is changed, for example when the viewable window is resized, the card view brings the anchor object and its row of cards, which may be referred to as an anchor row, into the viewable window. In this manner, the user context and the focus does not change and remains consistent when the card view structure is changed.
Referring back to
Referring to
Process 600 includes generating a card view from the virtual intermediate row-level objects (620). For example, the card view module 108 of
Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the scope of the embodiments.
