The present disclosure relates to computer-implemented methods, software, and systems for intuitive widget ordering in a workspace.
Dashboard workspaces allow information to be displayed through visually rich and personalized organizational layouts through the use of one or more widgets. A user can analyze and track a large amount of complex, changing, and often real-time information in an efficient manner using widgets in a workspace arranged in a logical orientation for the user or according to a predetermined orientation. This approach to presenting data leads to many possible issues, such as overlap of widgets if a widget is moved from its position in the workspace, the need to resize other widgets upon resizing a widget to avoid occluding data, and the inability to automatically and/or efficiently sort widgets in the workspace according to defined rules. Efficient handling of widgets in the workspace is essential for efficient and cost-effective use and management of the workspace, the widgets, and the often critical information presented through the use of the workspace.
The present disclosure relates to computer-implemented methods, software, and systems for intuitive widget ordering in a workspace. One computer-implemented method includes selecting a widget to add to a container widget, determining, using at least one computer, whether the selected widget has dimensional data, prefetching the selected widget, and retrieving content for the prefetched selected widget.
While generally described as computer-implemented software embodied on a non-transitory computer readable storage device that processes and transforms respective data, some or all of the aspects may be computer-implemented methods or further included in respective systems or other devices for performing this described functionality. The details of these and other aspects and implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.
Like reference numbers and designations in the various drawings indicate like elements.
The disclosure generally describes computer-implemented methods, software, and systems for intuitive widget ordering in a workspace. Specifically described is a workspace layout grid and associated algorithms to intuitively order widgets in the workspace through the use of the workspace layout grid.
The advantages of the present disclosure are numerous. First, a moving a widget within a workspace will result in automatic arrangement of overlapped widgets in order to preclude occluding of data and to eliminate the need to manually rearrange a workspace widget arrangement. Second, resizing a widget will also result in the automatic resizing of overlapped widgets in order to keep all widgets visible within the workspace. Third, widgets can be efficiently sorted based on criteria such as alphanumeric determination, timestamp, permissions, etc. Fourth, prediction of a size for a widget can be determined based upon widget-displayable content and other widget's dimensions and locations can be adjusted accordingly. Finally, workspace user satisfaction is enhanced. Other advantages will be apparent to those skilled in the art.
Turning to the figures,
In general, the server 102 is any server that provides support to the client 150 for intuitive widget ordering in a workspace using at least one business process 114 instance, at least one widget 115 instance, and at least one widget metadata 116 instance. In other implementations, the server can also provide support to the client 150 using at least a business application 108 and the at least one business process 114 instance, the at least one widget 115 instance, and the at least one widget metadata 116 instance. Although illustrated as residing locally to server 102, the at least one business process 114 instance, the at least one widget 115 instance, and the at least one widget metadata 116 instance may reside either locally or remote to the server 102. Although
For example, each server 102 may be a Java 2 Platform, Enterprise Edition (J2EE)-compliant application server that includes Java technologies such as Enterprise JavaBeans (EJB), J2EE Connector Architecture (JCA), Java Messaging Service (JMS), Java Naming and Directory Interface (JNDI), and Java Database Connectivity (JDBC). In some implementations, other non-Java based servers and or systems could be used for the server 102. In some implementations, each server 102 can store and execute a plurality of various other applications (not illustrated), while in other implementations, each server 102 can be a dedicated server meant to store and execute a particular business application 108 and related functionality. In some implementations, the server 102 can comprise a Web server or be communicably coupled with a Web server, where the particular business application 108 associated with that server 102 represents a Web-based (or Web-accessible) application accessed and executed on an associated client 150 to perform the programmed tasks or operations of the corresponding business application 108. In still other instances, the business application 108 can be executed on a first system, while the business application 108 manipulates and/or provides information for data located at a remote, second system (not illustrated).
At a high level, the server 102 comprises an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the example environment 100. The server 102 illustrated in
As used in the present disclosure, the term “computer” is intended to encompass any suitable processing device. For example, although
In the illustrated implementation of
The interface 104 is used by the server 102 to communicate with other systems in a client-server or other distributed environment (including within example environment 100) connected to the network 120 (e.g., an associated client 150, as well as other systems communicably coupled to the network 120).
Generally, the server 102 may be communicably coupled with a network 120 that facilitates wireless or wireline communications between the components of the example environment 100, that is the server 102 and the client 150, as well as with any other local or remote computer, such as additional clients, servers, or other devices communicably coupled to network 120, including those not illustrated in
As illustrated in
Regardless of the particular implementation, “software” may include computer-readable instructions, firmware, wired or programmed hardware, or any combination thereof on a tangible and non-transitory medium operable when executed to perform at least the processes and operations described herein. Indeed, each software component may be fully or partially written or described in any appropriate computer language including C, C++, C#, Java, Visual Basic, assembler, Perl, any suitable version of a 4GL, as well as others. It will be understood that while portions of the software illustrated in
A business application 108 is illustrated within the server 102 and may operate to execute business process-related events associated with at least one business process. Although illustrated as a single business application 108 in the server 102, two or more business applications 108 may be used in the server 102 according to particular needs, desires, or particular implementations of example environment 100. The business application 108 can be any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information associated with a particular server 102, particularly with respect to executing business process-related events associated with at least one business process. In particular, business processes communicate with other users, applications, systems, and components to send and receive events. In some implementations, a particular business application 108 can operate in response to and in connection with at least one request received from an associated client 150. Additionally, a particular business application 108 may operate in response to and in connection with at least one request received from other business applications 108, including a business application 108 associated with another server 102. In some implementations, each business application 108 can represent a Web-based application accessed and executed by remote clients 150 via the network 120 (e.g., through the Internet, or via at least one cloud-based service associated with the business application 108). For example, a portion of a particular business application 108 may be a Web service associated with the business application 108 that is remotely called, while another portion of the business application 108 may be an interface object or agent bundled for processing at a remote client 150. Moreover, any or all of a particular business application 108 may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure. Still further, portions of the particular business application 108 may be executed or accessed by a user working directly at the server 102, as well as remotely at a corresponding client 150. In some implementations, the server 102 can execute the business application 108. In some implementations, the business application 108 can be executed via a client 150 accessing the business application 108.
The server 102 also includes a memory 112 for storing data and program instructions. The memory 112 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), flash memory, removable media, or any other suitable local or remote memory component. The memory 112 may store various objects or data, including classes, widgets, frameworks, applications, backup data, business objects, jobs, Web pages, Web page templates, database tables, process contexts, repositories storing services local to the server 102, and any other appropriate information including any parameters, variables, database queries, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the server 102 and an associated business application 108. In some implementations, including a cloud-based system, some or all of the memory 112 can be stored remote from the server 102, and communicably coupled to the server 102 for usage. As illustrated in
The at least one widget 115 instance may represent a part of a GUI, made up of a collection of a number of GUI elements, such as a checkboxes, pull-down lists, buttons, etc., that allows a computer user to control and change the appearance of the GUI elements for operating a software application within a workspace. For example, the at least one widget 115 instance may be a network browser interface, a dialog box interface, an email application interface, a mobile device application interface, or other suitable part of a GUI. For the purposes of this disclosure, a “workspace” means a GUI environment, such as a computer desktop or within and application window, such as a browser, in which other widgets are displayed and/or manipulated. Note that a computer desktop may itself be considered a widget in that a computer desktop widget may be used to allow computer users to display and control various software applications, computer functions, etc. within the computer desktop widget. The at least one widgets 115 instance may contain and/or display various types of data, such as graphs, images, audio, video, or other suitable data, whether local or from a third-party content provider.
In some implementations, metadata associated with the at least one widget 115 instance can be stored with the widget 115 instance. The metadata may include, for example, type, name, title, language, resolution, dimension, optimum dimension, minimum dimension, maximum dimension, color, configuration, container, location, editability, security permissions, sub-components, layout grid dimension, layout grid granularity, layout grid column gap space, layout grid row gap space, or other suitable data value. Not all metadata types will apply to all widgets. In some implementations, only the applicable metadata will be associated with a widget. In other implementations, all metadata types can be associated with a widget with inapplicable metadata types given a value, such as NULL, to indicate they are not applicable to the widget. For example, if a particular computer desktop widget is the highest level widget possible, the particular computer desktop widget may have metadata establishing the resolution of the computer desktop as 1900×1080 pixels and a container value equal to NULL since nothing contains it. A user may be able to use the computer desktop widget and associated functionality in order to change the resolution metadata value to, for example, 1280×1024 pixels. In another example, a browser widget, when the browser widget is closed, may update a dimension metadata value to a current dimension of the browser widget, for example, a value of 900×600 pixels within the particular computer desktop widget resolution of 1280×1024. When the browser widget is re-started in the particular computer desktop widget, the browser widget may display itself with a dimension of 900×600 pixels after accessing the dimension metadata value. In other implementations, the metadata can be stored separately, either partially or completely, from the at least one widget 115 instance.
The third-party content provider 130 provides third-party content for consumption by the server 102 and/or the client. For example, a particular widget 115 instance may make a request for third-party content with which to populate the particular widget before the particular widget 115 instance is transmitted in response to a network request for the particular widget 115. Although illustrated as remote from server 102 and client 150, the third party content provider 130 may be incorporated into the server 102 and/or client 150 without departing from the scope of this disclosure as long as content from the third-party content provider 130 is available to some or all of the elements of example environment 100 via at least network 120.
In general, a client 150 is any computer device operable to connect or communicate with server 102 using a wireless or wireline connection (i.e., network 120). In particular, the client 150 may be embodied as a mobile or non-mobile computing device. At a high level, each client 150 can include a processor 154, a GUI 152, a client application 156, a memory 158, an interface 160, and an ordering engine 166. In general, the client 150 comprises an electronic computer device operable to receive, transmit, process, and/or store any appropriate data associated with it, a server 102, or other suitable data source.
The GUI 152 of the client 150 is operable to allow the user of the client 150 to interface with at least a portion of the system 100 for any suitable purpose, including to allow a user of the client 150 to interact with at least one client application 156, business application 108, and ordering engine 162. In particular, the GUI 152 may provide users of the client 150 with a visualized representation of the client application 156, business application 108, ordering engine 162, and other client 150 functionality. The GUI 152 may include a plurality of user interface elements such as interactive fields, pull-down lists, buttons, and other suitable user interface elements operable at the client 150.
In some implementations, processor 154 can be similar to processor 106 of the server 102. In other implementations, the processor 154 may be a processor designed specifically for use in client 150. Further, although illustrated as a single processor 154, the processor 154 may be implemented as multiple processors in the client 150. Regardless of the type and number, the processor 154 executes instructions and manipulates data to perform the operations of the client 150, including operations to receive and process information from the server 102 or other suitable data source, access data within memory 158, execute the client application 156 and/or ordering engine, as well as perform other operations associated with the client 150.
A client application 156 is illustrated within the client 150 and may operate to, among other things, support intuitive widget ordering in a workspace. Although illustrated as a single client application 156 in the client 150, two or more client applications 156 may be used in the client 150 according to particular needs, desires, or particular implementations of example environment 100. The client application 156 can be any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information associated with a particular client 150. In some implementations, a particular client application 156 can operate in response to and in connection with at least one request received from the client 150. Additionally, a particular client application 156 may operate in response to and in connection with at least one request received from other client applications 156, including a client application 156 associated with another client 150. In some implementations, the client-application 156 can use parameters, metadata, and other information received at launch to access a particular set of data from the server 102, including the at least one business process 114 instance, the at least one widget 115 instance, and the at least one widget metadata 116 instance. Once a particular client application 156 is launched, a user may interactively process a task, event, or other information associated with the client 150 or the server 102. The client application 156 may retrieve information from one or more servers 102 or one or more clients 150. Further, the client application 156 may access a locally-cached set of client-application-related information (not illustrated) stored on the client 150. In some implementations, each client application 156 can represent a Web-based application accessed and executed by clients 150 or servers 102 via the network 120 (e.g., through the Internet, or via at least one cloud-based service associated with the business application 108). For example, a portion of a particular client application 156 may be a Web service associated with the client application 156 that is remotely called, while another portion of the client application 156 may be an interface object or agent bundled for processing at a remote client 150. Moreover, any or all of a particular client application 156 may be a child or sub-module of another software module (not illustrated) without departing from the scope of this disclosure. Still further, portions of the particular client application 156 may be executed or accessed by a user working directly at the client 150, as well as remotely at a separate client 150, a server 102, or other computer (not illustrated).
The at least one layout grid 166 instance may be established within each widget instance that may contain (i.e., a “container” widget) another widget instance and act as a framework to mount and/or align widgets within the container widget. In some implementations, the ordering engine instantiates the at least one layout grid 116 instance and manipulates the at least one layout grid 116 instance. In some implementations, the at least one layout grid 166 can be a stand-alone widget and act as a container widget. For example, referring now to
In some implementations, metadata associated with the at least one layout grid 166 instance can be stored with the at least one layout grid 166 instance. The metadata may include, for example, dimension, optimum dimension, minimum dimension, maximum dimension, container, location, editability, security permissions, granularity, column gap space, row gap space, or other suitable data value. In other implementations, the metadata can be stored separately, either partially or completely, from the at least one layout grid 166 instance.
The at least one layout grid 166 instance also has a granularity. Returning to
An ordering engine 162 is illustrated within the client 150 and may operate to intuitively order widgets in a workspace using the at least one layout grid 166 instance. Although illustrated as a single ordering engine 162 in the client 150, two or more ordering engines 110 may be used in the client 150 according to particular needs, desires, or particular implementations of example environment 100. The ordering engine 162 can be any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information associated with a particular client 150, particularly with respect to intuitive widget ordering in a workspace. In some implementations, a particular ordering engine 162 can operate in response to and in connection with at least one request received from the client 150 or an associated server 102. Additionally, a particular ordering engine 162 may operate in response to and in connection with at least one request received from other ordering engines 110 and client applications 156, including an ordering engine 162 and client application 156 associated with another client 150. The particular ordering engine 162 may also respond to GUI events generated by various widgets, such as, resize events, movement events, and other suitable GUI events, whether local or remote. In some implementations, each ordering engine 162 can represent a Web-based application accessed and executed by the client 150. In some implementations, all or a portion of a particular ordering engine 162 can be a Web service associated with the ordering engine 162. In some implementations, all or a portion of the ordering engine 162 can be an interface object or agent bundled for processing. Moreover, any or all of a particular ordering engine 162 may be a child or sub-module of another software module (not illustrated) without departing from the scope of this disclosure. Still further, all or portions of the particular ordering engine 162 may be executed or accessed by a user working directly at the client 150, as well as remotely at a separate client 150, a server 102, or other computer (not illustrated).
The client 150 also includes a memory 158 for storing data and program instructions. Although illustrated as a single memory 158, the memory 158 may be implemented as multiple memories in the client 150. The memory 158 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), flash memory, removable media, or any other suitable local or remote memory component. The memory 158 may store various objects or data, including classes, widgets, frameworks, applications, backup data, business objects, jobs, Web pages, Web page templates, database tables, process contexts, repositories storing services local to the client 150, and any other appropriate information including any parameters, variables, database queries, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the client 150 and an associated client application 156 and/or ordering engine 166. In some implementations, including a cloud-based system, some or all of the memory 158 can be stored remote from the client 150, and communicably coupled to the client 150 for usage. As illustrated in
The at least one ordering algorithm 164 instance may represent rules, criteria conditions, parameters, variables, instructions, constraints, references, queries, and any other appropriate information used to intuitively order widgets in a workspace. For example, one or more algorithms may intuitively order widgets in a workspace by alphanumeric arrangement, rank, suggestions (automatic or user), removing empty space to consolidate, removing widget overlap due to resizing and moving, etc. A user may also define custom ordering algorithms unique to the user's needs. In some implementations, the at least one ordering algorithm 164 can be stored remotely from the client 150. The at least one ordering algorithm 164 may be accessed, for example, via a Web service, a remote access system or software, a local or remote client 150, the client application 156, the business application 108, or other suitable example environment 100 component.
The at least one widget 168 instance may be similar to the at least one widget 115 instance of the server 102. The at least one widget 168 instance may represent a copy of the at least one widget 115 instance to process locally on client 150 or a reference to the at least one widget 115 instance on server 102.
The at least one widget metadata 170 instance may be similar to the at least one widget metadata 116 instance of the server 102. The at least one widget metadata 170 instance may represent a copy of the at least one widget metadata 116 instance to process locally on client 150 or a reference to the at least one widget metadata 116 instance on server 102.
The interface 160 of the client 150 may be similar to the interface 104 of the server 102, in that it may comprise logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network 120. More specifically, interface 160 may comprise software supporting at least one communication protocol such that the network 120 or hardware is operable to communicate physical signals to and from the client 150. Further, although illustrated as a single interface 160, the interface 160 may be implemented as multiple interfaces in the client 150.
While
Initial Layout Grid Rendering/Subsequent User Actions
Referring now to
At 204, a layout grid is instantiated within the container widget. For example, the layout grid is instantiated within the browser. In some implementations, the layout grid is instantiated with a default granularity and number of columns and rows. In other implementations, the granularity and number of columns and rows are determined based upon metadata, such as the computer desktop widget resolution. In some implementations, the layout grid may be pre-populated with widgets. For example, the browser layout grid may have a clock widget, a weather widget, and a security widget pre-populated to render when the browser loads. From 204, method 200 proceeds to 206.
At 206, the container widget monitors for an indication of a user action. In some implementations, some other widget, software, or hardware may monitor for the user action and pass a notification to the container widget once the user action is determined. Although illustrated to monitor and direct adding and/or removing a widget from the layout grid, other user actions consistent with this application may be monitored and directed. For example, moving a widget, resizing a widget, etc. If at 206, the user action is to add a widget to the grid layout, method 200 optionally performs the functionality described below with respect to
At 210 a widget is removed from the container widget. For example, a user may have a clock widget in a workspace and decide to replace it with another type of clock widget. The user then uses the GUI to remove the clock widget from the container widget. After the removal of the widget from the container widget, there may be unused rows in the layout grid. From 210, method 200 optionally performs the functionality described below with respect to
Widget Pre-Fetch
Referring now to
At 304, a determination is made whether the loaded widget contains a dimension. In some implementations, the dimension can be retrieved from metadata associated with the widget. If it is determined that the widget contains a dimension, method 300 proceeds to 306. At 306, the widget is added to a layout grid associated with the container widget according to the contained dimension and the content associated with the widget is retrieved. In some implementations, the content may be retrieved from the client, the server or the third-party content provider to display within the widget. After 306, method 300 stops. If at 304, however, it is determined that the widget did not contain a dimension, method 300 proceeds to 308.
At 308, the loaded widget is pre-fetched from either the server memory and/or the client memory. From 308, method 300 proceeds to 310.
At 310, the content associated with the pre-fetched widget is retrieved as discussed above in 306. From 310, method 300 proceeds to 312.
At 312, a determination is made whether a prediction of the pre-fetched widget dimension may be made. For example, if the retrieved pre-fetch widget content contains an image of 300×300 pixels, the ordering engine could determine that a dimension of 300×300 pixels is appropriate for the pre-fetched widget. The predictive determination of the widget dimension may be made with various algorithms and content data types as would be apparent to one of ordinary skill in the art. If at 312, it is determined that a dimension prediction for the pre-fetched widget could not made, the method 300 proceeds to 314. At 314, the pre-fetched widget is added to the layout grid with a default dimension and the content associated with the widget is retrieved as discussed above in 306. In some implementations, the default dimension may be user defined or automatically determined by the ordering engine. After 314, method 300 stops. If at 312, however, it is determined that the pre-fetched widget contained a dimension, method 300 proceeds to 316.
At 316, a determination is made whether the determined dimension for the pre-fetched widget exceeds the container metadata dimension. For example, if the determined dimension of the pre-fetched widget is 300×300 pixels and the dimension of the container widget is 250×300 pixels. If at 312, it is determined that the metadata dimension does not exceed the container metadata dimension, method 300 proceeds to 318. At 318, the pre-fetched widget is added to the layout grid with the maximum container dimension and the content associated with the pre-fetched widget is retrieved as discussed above in 306. For example, if the determined dimension of the pre-fetched widget is 300×300 pixels and the dimension of the container widget is 1900×1080 pixels, the pre-fetched widget is added to the layout grid with a dimension of 1900×1080 pixels. After 318, method 300 stops. If at 316, however, it is determined that the metadata dimension does exceed the container metadata dimension, method 300 proceeds to 320. At 320, the widget is added to the layout grid with the pre-fetch dimension and the content associated with the pre-fetched widget is retrieved as discussed above in 306. For example, if the determined dimension of the pre-fetched widget is 300×300 pixels and the dimension of the container widget is 250×300 pixels, the pre-fetched widget is added to the layout grid with a dimension of 250×300 pixels. After 320, method 300 stops.
Overlapping Widgets
Referring now to
At 404, a widget collector 404a gathers information about all widgets in the current layout grid (e.g., position by column and row and width and height in layout grid cells). In some implementations, the widget collector 404a can access each widget's metadata 404b and retrieve dimension metadata. In other implementations, the widget collector 404a can determine the widget dimension in some other manner, such as using predictive analysis based upon content or some other suitable method consistent with this disclosure. In some implementations, the widget collector 404a can be an individual application, program, module, process, or other software that implements the various features and functionality through various objects, methods, or other processes. The widget collector 404a may also include a number of sub-modules, third-party services, components, libraries, and such, as appropriate. After 404, method 400 proceeds to 406.
At 406, a determination is made whether there are overlapping widgets. In some implementations, this determination is made by the ordering engine. If it is determined that there are overlapping widgets, method 400 proceeds to 408. At 408, the overlapped widgets to be repositioned are identified. Method 400 then proceeds to 410. If at 406, however, it is determined that there are no overlapping widgets, method 400 optionally performs the functionality described below with respect to
At 410, the overlapped widget's positions are recalculated and the overlapped widgets are repositioned within the containing widget to eliminate any widget position overlap. In some implementations, both the overlapping widget and the overlapped widgets may be repositioned. In some implementations, the recalculation of widget positions can be performed recursively. The present disclosure also contemplates recalculation of the overlapping widget positions by any suitable method. From 410, method 400 optionally performs the functionality described below with respect to
In the swap on drag scenario 418, a user is attempting to drag widget 420 over the position of widget 419. On the completion of the drag-and-drop of widget 420, widgets 419 and 420 are determined to be overlapping. As widget 420 was moved, its dimension and position is not affected further. Widget 419 has a new position calculated for it and is repositioned by swapping with the original position of widget 420 to eliminate the overlap of the widgets. While the swap on drag scenario 418 illustrates repositioning a widget vertically downward to eliminate overlap, the present disclosure contemplates repositioning overlapping widgets in many possible orientations.
Turning now to
In the double overlapping scenario 426, a user is attempting to resize widget 427 to a dimension overlapping the position of both widget 428 and widget 429. On the completion of the resize of widget 427, widgets 427, 428, and 429 are determined to be overlapping. As widget 427 was resized, its dimension and position is not affected further. Widgets 428 and 429 have new positions calculated for them and are repositioned by vertically repositioning widget 428 and widget 429 vertically downward to eliminate the overlap of the widgets. While the double overlapping scenario 426 illustrates repositioning widgets vertically downward to eliminate overlap, the present disclosure contemplates repositioning overlapping widgets in many possible orientations.
Remove Empty Rows Between Widgets
Referring now to
At 506, widgets in the container widget are repositioned. After 506, method 500 stops.
Resizing a Container Widget
Referring now to
At 604, dimensions for each cell are calculated using the width and height of the resized container widget in order to preserve the determined number of cells in the layout grid row. In some implementations, the width and height in pixels is used. In other implementations, a measurement other than width and height in pixels can be used. Method 600 proceeds to 606.
At 606, the calculated cell dimensions are cached. In some implementations, the calculated cell dimensions are cached in metadata. Method 600 proceeds to 608.
At 608, the layout grid is rendered within the container widget consistent with the calculated cell dimensions (i.e., a granularity modification). Note that all widgets in the layout grid are also dimensioned to remain within the visible portion of the container widget. On a resize of the container widget, widgets are re-dimensioned to conform to the newly resized container widget. In some implementations, a minimum threshold can be established for the rendered dimension of displayed widgets. Beyond the minimum threshold, displayed widgets may be reduced to icons, symbols, phrases, or other suitable representations of the widget. After 610, method 600 proceeds to 610.
At 610, a determination is made if the container widget was resized. If it is determined that the container widget was resized, method 600 proceeds to 604 as described above to recalculate the dimensions of the layout grid cells based upon the new dimension of the container widget.
Maximize a Widget within a Container Widget
In some implementations, non-maximized widgets and/or content can be reduced to smaller representative versions of themselves, for example to fit into a single layout grid cell or a determined number of cells of the containing widget layout grid. In other words, the entire widget, possibly including content, will be reduced in dimension and placed into a position in the container widget (i.e., the granularity of the non-maximized widget is changed). In some implementations, this determination is made by the ordering engine and/or ordering algorithms. In other implementations, the widget itself may not be reduced in size but a portion of the widget of the same dimension above, for example of a single cell or of a determined number of cells, may be excised from a widget and be used to represent a non-maximized widget (i.e., the granularity of the non-maximized widget is preserved). For example, if a widget had a title bar with the words “HI-TECH Calculator” and a representative non-maximized widget is only 50×50 pixels, if the entire widget is reduced (granularity is changed), the title bar words would all be visible in the reduced widget but rendered extremely small. If, however, only a portion of the widget were used (i.e., granularity of the non-maximized widget is preserved), the representative portion of the non-maximized widget may only have “Hi-Tech” displayed along with the widget portion content that fits within the specified dimension. In some implementations, the granularity setting may be user-selectable, automatically selected by the ordering engine and/or ordering algorithms, or by some other suitable method.
The preceding figures and accompanying description illustrate example processes and computer implementable techniques. But example environment 100 (or its software or other components) contemplates using, implementing, or executing any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any appropriate time, including concurrently, individually, in parallel, and/or in combination. In addition, many of the steps in these processes may take place simultaneously, concurrently, in parallel, and/or in different orders than as shown. Moreover, example environment 100 may use processes with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate.
In other words, although this disclosure has been described in terms of certain implementations and generally associated methods, alterations and permutations of these implementations and methods will be apparent to those skilled in the art. Accordingly, the above description of example implementations does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.
This application is a continuation of U.S. patent application Ser. No. 13/335,543 entitled “Smart and Flexible Layout Context Manager” filed on Dec. 22, 2011, the disclosure of which is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
Parent | 13335543 | Dec 2011 | US |
Child | 13403587 | US |