WO2003065191A2 - Method and apparatus for designing, rendering and programming a user interface - Google Patents
Method and apparatus for designing, rendering and programming a user interface Download PDFInfo
- Publication number
- WO2003065191A2 WO2003065191A2 PCT/CA2003/000132 CA0300132W WO03065191A2 WO 2003065191 A2 WO2003065191 A2 WO 2003065191A2 CA 0300132 W CA0300132 W CA 0300132W WO 03065191 A2 WO03065191 A2 WO 03065191A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- matrix
- user interface
- components
- size
- conceptual
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
Definitions
- the present invention relates to a method and apparatus for designing, rendering and programming a user interface.
- GUI graphical user interface
- PDA personal digital assistant
- pager the display is much smaller and the input device more limited. Accordingly, less sophisticated interfaces are usually used.
- Devices such as a PDA may still provide menus and windows to a certain extent, although the limited size inhibits them from using multiple windows. On a cell phone or pager with a very small display, windows may not be used at all.
- the development platform can be a specific Operating System platform (such as Windows, Linux, or the Mac OS) or a specific device such as PDA, or a cell phone.
- a hierarchy of proprietary components is used, creating an incompatibility between each other.
- These components are usually related to visual capacities and specific capabilities of the target platform (components such as windows and buttons are common on GUIs whereas small menus are used on wireless devices), extending the incompatibility between GUIs and wireless interfaces.
- components are usually related to visual capacities and specific capabilities of the target platform (components such as windows and buttons are common on GUIs whereas small menus are used on wireless devices), extending the incompatibility between GUIs and wireless interfaces.
- remote access is not available without external software and there is no multi-user collaboration functionality implemented.
- Mark-up languages such as HTML and XML are often used in Internet-based applications to work with several clients.
- the mark-up provides only one nominal view for the document. This view is usually not suitable for different types of devices.
- Web pages for PDA's and cell phones need to be created, and designed separately in WML rather than HTML to accommodate the limited interface. This requires additional design and development for each device of interest, and requires that the server know the destination device in order to choose the correct formatting.
- Java is an attempt to overcome the GUI incompatibility by offering its adaptable set of proprietary components.
- Java still offers at least three sets of UI components: AWT / SWING for GUIs, J2ME for wireless devices and JTAPI for vocal access. It also doesn't really run remotely since applets must be downloaded first before running locally on the client.
- None of the existing user interface components is really portable on different platforms creating a necessity of redesigning and recoding to support other existing platforms. All these incompatibilities between different user interfaces are noted in the following statement from the J2ME white paper:
- the present invention provides a conceptual user interface which may be rendered on any target device.
- the interface may be displayed by any target device.
- This methodology mitigates the problem of incompatibilities between the user interfaces of different platforms and also provides a new way of designing a user interface without having to think of where it will be deployed.
- the generic aspect and natural portability of the conceptual user interface generates a substantial relief for the software developers who are not obliged to understand the capabilities of the different platforms or devices. Instead, they may focus more on designing and defining the functionalities of the application than on accommodating it to run on specific platforms.
- this invention mitigates the user interface incompatibilities for the existing platforms and devices and will accommodate future platforms or devices.
- a method of displaying a user interface comprising the steps of: a) obtaining a representation of the user interface, the representation including conceptual components representing multi-dimensional arrays of elements of the user interface, said conceptual components including a vector parameter related to a multi-dimensional size of the array, and matrices having dimensions related to those of the array; b) executing a device-specific rendering algorithm on the representation of the user interface; c) displaying the user interface on the device.
- a method of encoding a user interface comprising the steps of: a) creating conceptual components representing a multi-dimensional array of elements of the user interface, said conceptual components including a vector parameter related to a multi-dimensional size of the array, and matrices having dimensions related to those of the array; and b) establishing connections between said conceptual components, said connections being indicative of relationships between said conceptual components.
- a method of selecting a layout for a user interface comprising the steps of: a) obtaining a semantic representation of the interface; b) generating a plurality of parses of the interface; c) measuring the suitability of each parse; d) choosing a parse with high suitability.
- a method of distributing a user interface to at least one of a plurality of client devices with differing input and output devices comprising the steps of: a) organizing the user interface into conceptual components representing multidimensional arrays of elements of the user interface, said conceptual components including a vector parameter indicative of a multi-dimensional size of the array, and matrices having dimensions corresponding to the array; and b) providing the representation of the user interface to at least one of the client devices to allow the client device to render the user interface using a selection of the matrices.
- a data carrier containing processor executable instructions to instruct a processor to encode a user interface by: a) creating conceptual components representing a multi-dimensional array of . elements of the user interface, said conceptual components including a vector parameter indicative of a multi-dimensional size of the array, and matrices having dimensions corresponding to the array; and
- a server device for providing an application to client devices, the server device comprising: a) an interface encoder for creating conceptual components representing a multidimensional array of elements of the user interface, said conceptual components including a vector parameter indicative of a multi-dimensional size of the array, and matrices having dimensions corresponding to the array; and for establishing connections between, said conceptual components, said connections being indicative of relationships between said conceptual components.
- a client device for executing an application by providing output to a user and receiving input from the user, the client device comprising: a) a processor; b) a storage device containing processor implementable instructions for obtaining a representation of the user interface, the representation including conceptual components representing multi-dimensional arrays of elements of the user interface, said conceptual components including a vector parameter indicative of a multi-dimensional size of the array, and matrices having dimensions corresponding to the array; b) a rendering engine operable on the representation of the user interface to produce a device-specific rendering of the user interface; and c) an output device for providing the rendering to the user.
- Figure 1 is a schematic representation of an application for use with devices
- Figure 2 is a schematic representation of a device in Figure 1;
- Figure 3 is a schematic representation of the conceptual interfacing process that occurs in Figures 1 and 2;
- Figure 4 is a schematic representation of elements layouts formulas and their corresponding output of a GUI user interface
- Figures 5A, 5B, 5C and 5D are schematic representations of data structures
- Figures 6A and 6B are schematic representations of renderings of the data structures of Figures 5A, 5B, 5C and 5D.
- Figure 7 is a schematic representation of a conceptual user interface stack
- Figure 8 presents an inheritance diagram of the UI conceptual components
- Figure 9 shows the general data structure and the modification methods of the UI conceptual component
- Figure 10A, 10B and 10C respectively describe the data structure and modification methods of the container, control and text conceptual components
- Figure 11 illustrates the meaning of the term Values Matrix for each Conceptual
- Figure 12A shows a example of a tree of Conceptual Components (CCs);
- Figure 12B shows the Rendered UI of a Container Conceptual Component with two child Conceptual Components;
- Figure 13 shows the different d-sizes (Base, Labels Matrix, States Matrix, Container,
- Figure 14 shows the effect of Constant Flags on the insert/remove methods
- Figure 15 shows in a real example the interaction between the Selections Matrix and the States Matrix;
- Figure 16 shows, for a Control conceptual component, some possible renderings calculated from different combinations of States Matrix d-sizes, Bitmap Size and String Max
- Figure 17A and 17B illustrate in a real example of the Children Direction influence on the rendering of a Container CC
- Figure 18 illustrates MDI windows that occur when End-User Resize flag of a 1- dimensioned CC is "true”.
- Figure 19A and 19B show the conversion of an n-dimensional coordinate to a 3- dimensional (Cartesian) system
- Figure 19C shows the reverse conversion from 3 -dimensional to n-dimensional system.
- Figure 20A shows the difference between the Matrix view and the element view
- Figure 20B shows the calculation rules of the element view for all CC types
- Figure 20C shows the User View for the Blackberry
- Figure 21 A shows the two steps for rendering a Conceptual Component into Native
- FIG. 1B shows that different device components (DCs) can be rendered using common native components
- Figure 22 shows the state machine composed of Windows device components as states, and their possible transitions when creating a device component tree
- Figure 23A to Figure 23H show, using flowcharts, the DC tree construction algorithm for the Windows GUI;
- Figure 24A to Figure 24E show, using flowcharts, the NC construction algorithms for the Windows GUI;
- Figure 25 shows an example of the rendering of a Calculator Conceptual UI using
- Figure 26 shows the DC tree navigation principle applicable to platforms with limited user interface capabilities
- Figure 27 shows a parsing example through a large Schroder sequence of 4 elements
- Figure 28 to Figure 28E show types used to design the GUI layout algorithm
- Figure 29A to Figure 29N show, using flowcharts, a layout parsing algorithm
- Figure 30A and Figure 30B show, using flowcharts, an evaluation algorithm applicable to all layouts generated by the layout parsing algorithm
- Figure 31A to Figure 3 ID show, using flowcharts, a layout display algorithm
- Figure 32A to Figure 32E show, using flowcharts, Line methods used in the layout display algorithm.
- Figure 33 shows a relationship between types and objects in the Conceptual interfacing process.
- an application environment is shown generally by the numeral 10.
- an application 12 incorporates a user interface 14.
- Users of various devices 16a, 16b, 16c, and 16d are used to run the application 12.
- the devices may be connected to the application 12 through a network, or alternations may be directly connected thereto.
- the application 12 may be incorporated into the devices 16.
- the users interact with the application 12 through the interface 14.
- the devices 16a, 16b, 16c, and 16d may include stand alone computers, laptops, cellular telephones, pagers, and the like. Each of these devices has different capabilities in its interface.
- a sample device is shown by the numeral 16.
- the device includes a processor 18, the storage 20, an output device 22, a rendering engine 26, and an input device 24. It will be appreciated that the form of these components differs for each device. Some devices may have faster and larger processors 18. Other devices may have more or less storage 20.
- the nature of the output device 22 may vary from a full screen display to a very small black and white display or an audio device such as headphones or speakers.
- the input device 24 may be a keyboard, a mouse, a touch screen or even a voice interface.
- the rendering engine 26 will therefore vary with each device and is tailored to the abilities of the input and output devices. Further details of the nature of the rendering engine will be provided below.
- the interface 14 is encoded in a conceptual manner.
- the conceptual user interface may be provided to any device 16a, 16b, 16c, or 16d where, with reference to Figure 2, the proprietary rendering engine 26 produces a rendered user interface to present on the output device 22.
- FIG. 3 schematically shown therein is the flow of information between the Application Logic 12 and an End-User 17.
- the Conceptual User Interface (UI) 14 is created by using Conceptual Components, which will be explained below.
- the Conceptual UI 14 is then converted into a Rendered UI 15, using algorithms proprietary to the targeted client platform/device, to be finally interpreted by the End- User 17.
- the End-User 17 may modify the Application Logic 12 by applying actions to it.
- the Conceptual Interfacing methodology 25, includes the Conceptual UI 14 and the Rendered UI 15.
- the Rendered User Interface 15 which is a presentable version of the Conceptual UI 14, by generating in real-time a visible and interactive user-interface according to the specifications and capabilities of the End-User 17 target platform/device.
- FIG. 30 one aspect of the layout rendering suitable for a GUI is shown generally by the numeral 30.
- the layout rendering includes an operator denoted as pipe a vertical bar
- b) - c shown as numeral 32 therefore corresponds to the notional display at numeral 34 where elements a and b are side by side and element c is underneath the block a and b.
- the conceptual components may be referred to as multi dimensional matrixes. These may be of three, four or more dimensions and accordingly do not easily correspond to a real world depiction. By way of example, therefore a 2 x 2 matrix is shown in Figures 5A, 5B, 5C, and 5D by way of introduction. Higher dimensional structures will be explained below.
- a labels matrix is shown generally by the numeral 40.
- the labels matrix is 2 x 2, and each cell contains a label, shown as A, B, C, and D.
- the label may be text or a bitmap and is Used to identify the component to the user.
- a read only flag matrix is shown generally by the numeral 42.
- Each cell of the matrix contains an indication of either yes or no. Typically, this will be encoded as 1 's and O's in binary.
- the flag matrix is used to control whether elements may be modified by the user.
- FIG. 5C an images matrix is shown generally by the numeral 44. Each cell of the matrix corresponds to an optional image that constitute a tailored rendering if desired by the programmer.
- Figure 5D shows a values matrix 46 where the entries, in this example selections for a control component from an empty separate state matrix, correspond to those in Figures 5A, 5B and 5C. In this example, these matrixes taken together represent a control component of a user interface.
- FIG. 6A and 6B example renderings of the structure shown in Figures 5A, 5B, 5C, and 5D is shown by the numerals 50a and 50b.
- the labels matrix 40 is not used in the display, only the images. The images would have the functionality of buttons, since they belong to a control component.
- the interfaces rendered using text in the labels matrix 40 This may be used on a device where the display 22 is limited in capability. Therefore, the labels matrix 40 is used to designate each possible choice. Again, they would appear as buttons with labels inside, this time borrowing the target device look and feel.
- a Conceptual UI is a user-interface model composed of abstract components such as containers, controls and texts instead of device-specific components such as windows, forms, buttons, menus, check boxes and edit boxes.
- a mathematical model is used. This mathematical model includes multi-dimensioned numbers, vectors, sets, matrices, trees and matrices of trees. Only mathematically proven concepts make possible the transition from a device-capabilities-based model (such as Win32, AWT, RIMOS) to a fully user-need-based model (Conceptual UI).
- FIG. 7 the implementation of a Conceptual UI is a simple Stack 62 of references to conceptual components, detailed in the next section. References in the stack may be null as well (the reason will be explained later). Both stack and conceptual components are entirely managed by the application logic 12.
- the application logic 12 created by the programmer, can create conceptual components by defining them and calling their constructors. He can then add the references of the newly created conceptual components to the Conceptual UI Stack 62 via the Push(CC) 65 method, and can later remove existing references from the Conceptual UI Stack 62 by calling the PopQ 70 method. The push and pop methods will be explained in details shortly.
- the Conceptual Component may be understood as the base unit defining user- interface information presented to the user.
- a Conceptual Component When a Conceptual Component is created in the application, it is not immediately rendered to the user. The rendering of this Conceptual Component to the user happens only when the programmer adds the conceptual component's reference to the Conceptual UI Stack 62.
- a Conceptual Component not referenced in the Conceptual UI Stack 62 is considered "unlinked”. Referring to Figure 1, the Conceptual Component 60a and the Conceptual Component 60b are linked, whereas the Conceptual
- Component 60c is unlinked.
- the Conceptual UI Stack 62 is always empty. Like any stack, the Conceptual UI has two methods: Push(CC) 65 and PopQ 70.
- the Push(CC) 65 adds a reference, at the top of the stack, that points to either a valid
- Component (if any) becomes read-only. User interaction always takes place only on the
- the Pop() 70 method removes the last pushed reference from the top of the stack.
- GUI Conceptual User Interface
- Containers that are sets of elements. Some elements within a container may be containers as well, allowing a hierarchical organization of the elements required to build a user- interface.
- a complex hierarchy of component types is declared to express those three UI basic types.
- windows, forms and menus are examples of containers; buttons, check boxes, list boxes, menu items are examples of controls; text fields, edit boxes, and note boxes are examples of texts.
- the three UI basic types have been mapped into three and only three Conceptual Components. These Conceptual Components encapsulate all the required container, text and control functionality making it possible for the software developer to design a complete and effective conceptual user-interface. Consequently, a conceptual user-interface is fully portable across all platforms and devices.
- a Conceptual Component is the base unit of a conceptual user-interface that can become a container, a control or a text.
- Conceptual Components include Container CCs, Control CCs and Text CCs. These are the three CC types.
- An abstraction model is used to organize in a user-friendly way many values that will be presented and modified by the end-user. To be efficient for the rendering on various client devices, a user-interface abstraction model needs to distinguish between homogeneity and heterogeneity for its values: which ones have the same attributes (e.g. a two-dimensioned array of text cells in a spreadsheet application) and which ones don't (e.g. a set of controls and texts). Thus a CC should be able to hold multiple values if necessary, to implement the concept of homogeneity (for example, in Windows a list box holds a 1-dimensioned array of states). For this reason, each CC has a matrix of values. The value type depends on the CC type.
- the value type of a Container CC is a set of other CCs (and some of them can also be Container CCs, which makes up a CC tree).
- the value type of a Text CC is an editable text.
- the value type of a Control CC is a selected state.
- Each value within the CC is also associated with an image.
- a value is composed of a CC set, a text or a selected state and an image. If the image width and height are greater than zero in the application logic, the image will be used in the rendering when possible (mostly in GUIs), since not all user interfaces can display graphics.
- FIG. 8 an inheritance diagram is shown representing the three CCs needed to build conceptual UIs.
- the Container CC 72, the Control CC 74 and the Text CC 76 are all inherited from the CC 60.
- the CC 60 contains the common functionality of Container, Control and Text CCs. And since any CC value can be represented by an image, the image processing resides in the CC 60 base class. So, the three CC types are sufficient to define any user interface.
- both d-numbers have the same number of dimensions and that the operator is applied for the corresponding values of the two operands for all dimensions.
- ⁇ 3, 4 ⁇ ⁇ ⁇ 6, 5 ⁇ is "true” because 3 ⁇ 6 and 4 ⁇ 5, but ⁇ 1, 3 ⁇ ⁇ ⁇ 2, 2 ⁇ is "false", since 1 ⁇ 2 but 3 > 2 (the operator ⁇ is "false” for the second dimension).
- the 0 in fact means a d-number that has a number of dimensions equal to that of the other operand and that all values are 0.
- the Od-size ⁇ always has 1 unit. The units within the d-size are undefined.
- a d-coordinate is a d-number used to locate a unit within a d-size.
- the coordinate must always have the same number of dimensions than its corresponding d-size.
- d-coordinate > 0
- a d-coordinate should be 3-dimensioned and can vary between a minimum of ⁇ 0, 0, 0 ⁇ and a maximum of ⁇ 6, 5, 2 ⁇ .
- the Od-coordinate unit always refers to the only unit of Od-number ⁇ .
- the concept of a matrix is a collection of values of the same type, located into the units of a multi-dimensioned area.
- the matrix always has a d-size and content, which is the set of elements.
- Elements of the matrix can be of any data or object type (number, structure, array, even another matrix).
- the CC 60 contains Data 105 and Modification Methods 110.
- the Data 105 of the CC encapsulates three matrices that, along with the Values Matrix, will form the complete user information: the Labels Matrix 115, the Read-Only Flags Matrix 120 and the Images Matrix 125.
- the Modification Methods 110 are methods used to modify or update the Data 105 of the CC 50. In the Modification Methods 110 column, "Initialization time" always means that the associated Data 105 member is set once at the creation of the CC. All information set at Initialization time cannot in any way be modified for lifetime of the CC.
- the Base d-size 150 entered at Initialization time will be used as the foundation for the calculation of the Labels Matrix 115 d-size, Read-Only Flags Matrix 120 d-size, Images Matrix 125 d-size and also the Values Matrix d-size.
- the Base d-size 150 is used to calculate these four different d-sizes that are used by the CC. The calculation of those d-sizes from the Base d-size 150 will be explained in further sections.
- Constant Flags 175 is a list of flags used to put constraints on the Base d-size 150.
- the number of elements in this list of flags is equal to the number of dimensions of Base d-size 150 to have one Constant Flag 175 per Base d-size 150 dimension.
- one Constant Flag 175 is "true”, it means the corresponding Base d-size 150 value, specified at CC Initialization time, cannot be modified afterwards.
- the Base d- size 150 value still set first at Initialization time, can grow or shrink via insertion or removal of elements.
- the Variable d-size is a d-size that includes only the dimensions of the Base d-size 150 where the Constant Flags 175 is "false"; this means the Variable d-size can have a number of dimensions less or equal than the Base d-size 150.
- the Constant Flags 175 can have a number of dimensions less or equal than the Base d-size 150.
- a Base d-size 150 of ⁇ 2, 3 ⁇ and Constant Flags 175 equal to ⁇ true, false ⁇ which means the first dimension value of the Base d-size 150 (2) is constant (constant flag is "true” on the first dimension), however the second dimension value of the Base d-size 150 (3) can grow or shrink (constant flag is "false” on the second dimension).
- the Variable d-size in this case includes only the second dimension where Constant Flag 175 is "false", resulting in a Id-size of ⁇ 3 ⁇ .
- Constant Flags 175 are also used for the rendering.
- a practical illustration of the use of the Constant Flags 175 in the rendering is scroll bars existing in Windows. For example, when the number of elements displayed in a window is constant on the horizontal direction (i.e. Constant Flag 175 is "true” on the first dimension) there is no need for a horizontal scroll bar since all the existing elements are already displayed. However if the number of elements can grow (i.e. Constant Flag 175 is "false” on the first dimension), there must be a horizontal scroll bar that enables the end-user to scroll all over the elements. The same concept applies on the Vertical direction in Windows (considered in this example the second dimension). This shows that the modification of the Constant Flags 175 over any dimension can result in a modification of the final rendering of the client device.
- the End-User Resize Flags 180 are, just like the Constant Flags 175, a list of flags, and the number of elements is also equal to the number of dimensions of Base d-size 150 in order to have one End-User Resize Flag 180 per Base d-size 150 dimension.
- a Resize Flag 180 with value "true” means that the end-user is allowed to change the corresponding Base d-size 150 value by sending insert/remove events to the Conceptual Component.
- a "false” flag means the end-user cannot insert/remove units from the corresponding Base d size 150 value. Therefore, the user is forbidden to send insert/remove events.
- the End-User Resize Flag 180 is automatically set to "false” on this dimension. The user cannot change the size of a dimension when it is already set constant. However if the Constant Flag 175 is "false”, the End-User Resize flag 180 can be "true” or "false", allowing or prohibiting the end-user to change the dimension size.
- a practical illustration of the use of the End-User Resize Flags 180 is a multiple document interface (MDI) in Windows. In the conceptual UI model, a MDI window is presented by a CC of 1-dimensioned matrix, where the Constant Flag is set to ⁇ false ⁇ .
- any of the documents (documentl 1050, document2 1055, document3 1060) is subject to insertion/removal.
- the end-user is allowed to close an existing document and create a new document (End-User Resize Flag is "true").
- the Directions 185 data member is a list of directions, and the number of elements is also equal to the number of dimensions of Base d-size 150 in order to have one Direction 185 per Base d-size 150 dimension.
- Each Direction 185 in the list takes one of the three possible values: Width, Height or Depth. It specifies the direction of its corresponding Base d-size 150 dimension that will preclude when the CC is rendered to the user. Any rendering must occur in a 3-dimensional space, which forces conversion back and forth between abstract n-dimensional CCs and its corresponding concrete, rendered 3-dimensional space (those n-dimensioned to 3-dimensioned and 3-dimensioned to n-dimensioned conversions will be explained below).
- the Directions 185 are used in the rendering for this conversion process.
- the Default Action Flag 190 if set to "true”, specifies that no event generated from user interaction in the CC will be passed on to the application logic, for further processing. Instead, the default behavior of user interaction in the CC will take place, without notifying the application that a change has occurred. For example, for most text-entry fields, the application never changes its normal behavior based on modification events such as additions and removals of letters, and therefore the application should not know about these events.
- the Default Action Flag 190 if set to "true”, can considerably speed up processing when there is a long delay between the user interaction on the client device and the reception of the event by the application.
- Default Action Flag 190 is set to false, user input is temporarily disabled when the user modifies the component.
- the user input will be re-enabled when the Push(CC) 65 (the CC may be null) and then PopQ 70 methods in Figure 7 are called.
- the user is prohibited from entering other information while a previous command is still executing. For example in an address book, after the user has entered the first name, surname and phone of a contact he presses a submit button, he must be prevented from typing other information while the submission is being processed. Any attempt to modify the application at this time will be discarded, ensuring a safe use of the application.
- the Tree Flag 192 if set to "true”, specifies that the CC matrix will instead be implemented as a tree of homogeneous values. It is a practical flag for creating trees of values that look similar. An example among others is the Tree View in Windows. Thus, if the Tree Flag 192 is set to "true", the Base Size 150, the Constant Flags 175, the End-User Resize Flags 180 and the Directions 185 are irrelevant and therefore not used for the CC 50. Only the number of dimensions from the Base Size 150 would be required, because in many cases, we want to limit the number of levels the tree may have. For trees that require "unlimited” number of levels, just put a large number of dimensions is put in Base Size 150.
- the int insert(dnum start, dnum range) 155 and int remove(dnum start, dnum range) 160 method are still used, this time to add or remove values in the tree.
- the start parameter is the path in the tree where the insertion/removal happens.
- the range parameter specifies how many values to insert/remove. Usually, range in this case should be a Id-number, but nothing prevents an implementation with multiple dimensions. In this case, the first dimension would be the number of elements on the start level, then, on the next level, the second dimension would be inserted for each element of the first dimension, and so on. Renderings should include expand/collapse options to manipulate the tree.
- the Tree Flag 192 default value is "false”, if not defined at Initialization time.
- the Semantic Type 195 is a string that is used to identify a convention if applicable. Many applications have user interface fields that refer to known conventions, such as date, time, phone number, postal code, password, etc. Many user interfaces have specific controls (semantic controls) that handle these commonly used fields. Their look and feel might be different across platforms, but ultimately they refer to the same human convention.
- the Semantic Type 195 string will be one entry from a pool of predefined convention strings like "date”, “time”, “zip code”, and "password”. If the user interface does not have a semantic control for a given convention, the Semantic Type 195 string is not used. An empty string in the Semantic Type 195 indicates that the CC does not refer to any human convention.
- the User-Defined Flags 200 respectively address the Labels Matrix 115, the Readonly Flags Matrix 120 and Values Matrix (including the Images Matrix 125). Further details about the three matrices will be given below, however they may be considered generally as matrices of user information elements. By default, these information elements will be stored in internal memory by the Rendered UI, on behalf of the programmer. However, if a User-Defined Flag 200 is "true", its corresponding information elements must instead be defined by the programmer in his source code, that is in the application logic 12 (only the viewed part of the information will reside in the Rendered UI memory, for displaying purpose).
- the programmer will have to redefine the retrieval methods to get accurate data from its proprietary storage mechanism.
- the User-Defined Flags 200 are usually required when the information consumes too much memory to be blindly stored by the Rendered UI internal mechanism. For example, in an Excel sheet, the cells are not all stored in Windows Rendered UI memory using a huge string array. In this case, the Excel programmer holds a structure where only the non-empty cells are stored.
- the programmer of a conceptual Excel application must set the sheet component User- Defined Flag 200 for the Values Matrix to "true" and establish links between the sheet component and his own structure by redefining the retrieval methods.
- the User-Defined Flags 200 are also useful when all the corresponding information elements can be retrieved using a mathematical formula.
- the Labels Matrix 115 is used to describe the Values Matrix to the user.
- a label is a small description that is composed of a text string and/or a bitmap.
- the Labels Matrix d-size 755 is equivalent to the Base d-size 150.
- the String Max Length 215 contains the maximal length the text string of any label in the Labels Matrix 115. If the String Max Length 215 if 0, no text string can be entered within labels.
- the Bitmap Size 220 specifies the size, in pixels, of all bitmaps in Labels Matrix 115. If the Bitmap Size 220 width and/or height are equal to zero, then the Labels Matrix 115 cannot contain any bitmap.
- the Labels Matrix 115 content will be either stored in a Buffered Storage System 225 residing in the application logic 12, the Default Storage System 230 residing in the CC or a User- Defined Storage System 245 residing in the application logic 12, depending on the label User- Defined Flag 200 and the Constant Flags 175.
- the label User-Defined Flag 200 is set to "false” and for all Base d-size 150 dimensions, the Constant Flag 175 is "true” (constant), the Buffered Storage System 225 is used. In this case, the application must supply at initialization time a buffer of length (String Max Length 215 + 1) x Product of Labels Matrix 115 d-size.
- the buffer contains the text strings if String Max Length 215 is greater than 0 and, if Bitmap Size 220 is not null, a buffer of length Size Of Bitmap Structure x Product of Labels Matrix 115 d-size that will contain bitmaps.
- the label User-Defined Flag 200 is set to "false” and at least for one Base d-size 150 dimension a Constant Flag 175 is "false” (not constant), the Default Storage System 230 is used. Empty label elements can be created with insert(dnum start, dnum range) 155.
- the label User-Defined Flag 200 is set to "true"
- the User-Defined Storage System 245 is used.
- the updatelabels(dnum pos, dnum range) 250 can be used to refresh the label . rendering whenever a corresponding change in the proprietary label storage mechanism of the application logic has occurred.
- the Read-Only Flags Matrix 120 content determines whether or not the Values Matrix elements enable user input. If "true” user input is disabled, otherwise it is enabled.
- the Read-Only Flags Matrix d-size 785 is equivalent to the Values Matrix d-size 780. The calculation of the Values Matrix d-size 780 is explained later in this document.
- the Read-Only Flags Matrix 120 values can be set to "true” or “false” to forbid or allow user editing on the corresponding Values Matrix elements within the CC.
- the Read-Only Flags Matrix 120 content will either be the Default Storage System 275 residing in the Rendered UI or a User-Defined Storage System 285 residing in the application logic, depending on the read-only User-Defined Flag 200.
- the read-only User-Defined Flag 200 is set to "false"
- the Default Storage System 275 is used.
- the read-only User-Defined Flag 200 is set to "true”
- the User-Defined Storage System 275 is used.
- Method updateroflags (dnum pos, dnum range) 290 will refresh the readonly flag rendering whenever a corresponding change in the proprietary read-only storage mechanism of the application logic has occurred.
- the Images Matrix 125 is used by the application logic to express CC values (either containers, control selections or texts) with a graphical representation.
- the Images Matrix d-size 790 is equivalent to the Values Matrix d-size 780.
- the calculation of the Values Matrix d-size 780 is explained later in this document.
- an image is a two-dimensioned array of pixels.
- the 2D size 320 specifies, in pixels, the width and height of all images in the Images Matrix 125. It is set at Initialization time. Both width and height must be greater than or equal to 0. If 2D size 320 is not 0 for width and height, and the values User-Defined Flag 200 is set to "false", the images are stored in a Default Storage System 325 and can be modified via a set of Text & Graphical Commands 330.
- the application logic may use the Images Matrix 125 to precisely control the rendering and user input of each Values Matrix element (Children Set instance, selection or text as explained with reference to Figure 11).
- the rendering process of the Values Matrix is decided as follows. o If the Rendered UI targets a sophisticated platform where the user can view/manipulate images and the Images Matrix 125 is used (that is, the 2D size 320 applicable to all images is not null), the Images Matrix 125 takes precedence over the Containers, Selections or Texts Matrix and images are displayed.
- the Values Matrix d-size is calculated from two factors: d-size accumulation and Container d- size.
- D-size accumulation happens when each element of a matrix is another matrix, as it happens in CC trees.
- a two-dimensioned matrix of d- size ⁇ 4, 2 ⁇ may contain elements that are three-dimensioned matrices of d-size ⁇ 3, 5, 2 ⁇ .
- the d- sizes of the two matrices can be accumulated to form one matrix of d-size ⁇ 4, 2, 3, 5, 2 ⁇ (e.g. ⁇ 4,
- D-size accumulation is associative (e.g. ⁇ 4, 2 ⁇
- the Container d-size 770 of a CC is itself an accumulation of all the Base d-sizes 150 of its parent Container CCs, from the root Container CC to the Container
- the Container d-size 770 to exist, must apply to a linked
- FIG. 12A shows a linked CC tree with the base d-size of each CC (the Container CC 72c has no children).
- the Root Container CC 72a will always have Container d-size ⁇ (1 unit).
- the CC 60d and Container CC 72b Container d-size is ⁇ 2, 4 ⁇ (8 units), since they are the children of Root Container CC a.
- the CC 60e and CC 72c Container d-size is ⁇ 2, 4, 5 ⁇ (40 units).
- This Container d-size is the accumulation of CC 72a and Container C 72b base d-sizes.
- the Values Matrix d-size 780 is the d- size Accumulation 775 of its Container d-size 770 and its own Base d-size 150.
- the Values Matrix d-size of Container CC 72c would be ⁇ 2, 4, 5 ⁇
- ⁇ 4, 3, 2 ⁇ ⁇ 2, 4, 5, 4, 3, 2 ⁇ (960 units).
- a Container CC 72 is used as a set of other CCs, referred to as child CCs.
- a Container CC 72 is used to build complex user interfaces, by building a tree of CCs.
- a Container CC 72 may end up, for example, as a menu or a window containing controls built from child CCs.
- the Children Set 365 is a list of references to child CCs associated to optional labels (made of text strings and bitmaps) that must be given at initialization time.
- the Children Set 365 can be empty if desired.
- the Children Set 365 is subject to restrictions if the Semantic Type is not null and refers to a valid convention. In this case, the Children Set 365 (and all the descendants) must follow that convention to be effective.
- the Read-Only Flags Matrix values and the user-defined flag for values of the Container CC 72 also apply for all the child CCs values. For example, if a Container CC 72 is not editable (read-only flag is "true") its entire child CCs are not editable as well.
- Each child CC also contains an internal Parent variable that will always reference its current Container CC 72.
- the Parent variable is set to null. Only CCs where Parent is null can be pushed in and popped out of the CUI.
- the Root Container CC 72 of each tree is the Container CC 72 that is directly referenced by the CUI.
- the Children Set 365 of the Container CC 72 is set at Initialization time, the order of creation of the CCs that will be part of a CC tree becomes fundamental. CCs must be created following their bottom-up order in the tree.
- a convenient creation order of the CC tree is by first creating CC ⁇ 7, 3 ⁇ 60d, then CC ⁇ 60e, then Container CC ⁇ 4, 3, 2 ⁇ 72c, then Container CC ⁇ 5 ⁇ 72b that immediately references CC ⁇ 60e and Container CC ⁇ 4, 3, 2 ⁇ 72c at initialization time, and finally Root Container CC ⁇ 2, 4 ⁇ 72a, which references CC ⁇ 7, 3 ⁇ 60d and Container CC ⁇ 5 ⁇ 70b at Initialization time.
- the destruction order of the CCs in the CC tree always happens in the reverse order of their creation.
- the Container CC 72 uses the Children Set 365 to define the unit of its Values Matrix.
- the Children Set 365 is seen as a structure, an organization, a type, a template or a model that cannot be modified throughout the Container CC 72 lifetime. Instances of this Children Set 365 structure will populate the Values Matrix.
- the Container CC 60d has two children, namely CC A 60f and CC B 60g, that could be of any CC type.
- the Values Matrix which d-size is ⁇ 3 ⁇ , will have instances of the set composed of CC A 60f and CC B 60g. Since the base d-size of CC A 60f is ⁇ 2 ⁇ , each unit in the Container CC 72d Values Matrix will have two instances of CC A 60f. Since the base d-size of CC B 60g is ⁇ 3 ⁇ , each unit in the Container CC 60d Values Matrix will have three instances of CC B 60g.
- the rendered UI (RUI 750) shows the layout of the output rendered to the end-user and the coordinates of CC A 60f and CC B 60g values.
- the Children Direction 370 specifies the direction on which all child CCs will be represented, when rendered to the user.
- the Children Direction 370 takes one of the three possible values: Width, Height or Depth, always considering that the rendering is occurring in a 3-dimensioned space.
- the Children Direction 370 gives the user the ability to choose the space direction where child CCs accumulate. It is strictly applied when the Container CC has dimensions in its Values Matrix. However, when the Container CC has no dimension in its Values Matrix (its Children Set 365 is displayed once and is never replicated), the Children Direction 370 is superseded by the device proprietary field positioning rules. In this case, the children are positioned according to the client device conventions.
- the Children Direction 370 might still influence the rendering, which is why it is important to define it even when there is no dimension in the Values Matrix.
- the tax credit form 1000 has a Children Direction of Width or Height, which means all fields (Name 1005, Address 1010 and Age 1015) are displayed on the same panel.
- the rendering corresponds to a Tab Control 1025 where each tab item (Name 1030, Address 1035 and Age 1040) refers to one piece of information (one child CC) and the end-user can switch between tab items.
- the Container CC 72d and the CC A 60f have one dimension along the width, whereas the CC B 50g has one dimension along the height, as shown in the rendered UI (RUI) 750.
- the Select CC Flag 375 set at Initialization time, enables the application logic 12 to force the end-user to use only one child at a time. When true, the end- user can only interact with the child CC indexed by Selected CC 378. The application logic 12 can modify the Selected CC 378 with method selectccftnt childindex) 385, allowing the end-user to interact with another child. If the childindex parameter is less than 0 or greater than the number of child CCs in the Children Set 365, no child CC is presented to the end-user to interact with.
- the Instances Matrix 360 which is the Container CC 60 Values Matrix, holds the instances of the Children Set 365.
- An implementation might include labels (both strings and bitmaps) naming each child CC. Even if child CCs have their own labels, they might be matrices and therefore not have a single label defining the whole matrix. Therefore, each element of the Children Set 365 can have an extra label.
- a Control CC 74 includes a States Matrix 405 containing the states and a Selections Matrix 400 (which is the Control CC 70 Values Matrix) storing the different selection d-coordinates of States Matrix 405 units. These selections are available for the end-user to control the application logic behaviour. The following example clarifies the difference between a State and a Selection.
- a Control CC 74 is presented with all its Data Members 105 and their actual Value 505. As shown, the Control CC 74 has a Base d-size 150 of ⁇ 2 ⁇ and "me:" "you:” as label strings.
- the States Matrix of the Control CC 74 has a d-size of ⁇ 4 ⁇ and "A", "B", "C”, "D” as label strings.
- the rendering of the Control CC 70 comprises two combo boxes having both the same States Matrix (4 states).
- the rendering rules that were used in this example will be explained in a later section of this document.
- the end-user current combo box selections are "B” and "D”.
- the Selections Matrix will be composed of two d-coordinates indicating the right states indexes, namely ⁇ 1 ⁇ and ⁇ 3 ⁇ . This example shows that the States Matrix and the Selections Matrix are different but complementary for building complete and complex controls.
- the States Matrix 405 as for the CC 60 from Figure 9 is constituted from:
- a States Matrix d-size which similar to the Base d-size is the d-size of the States Matrix 405.
- Figure 16 shows the interaction between the States Matrix d-size 760, the Bitmap Size 220 and the String Max Length 215 when it comes to rendering the CC.
- the rendering shown takes the three values into account, but can be different from one platform to another (it is shown with Windows in the example) and also from one context to another. Within a menu context for example, menu items would be chosen for the rendering.
- the states are composed, when String Max Length 215 is > 0, from labels extracted from the states Labels Matrix. For States Matrix dimensions where String Max Length 215 is zeroed, the States are unnamed.
- Bitmap Size 220 was null (there is no bitmap). In the case Bitmap Size 220 was not null, the rendered components would have had a bitmap associated to a string (if String Max Length 215 is > 0) or only a bitmap (if String Max Length is 0). A rendering possibility is also shown for each case. It will be seen that the choice of different Windows components is not discussed in the samples shown in Figure 16. The rendering rules will be discussed in detail in further detail below.
- the Selections Matrix 400 (the Control CC 74 Values Matrix) holds all the selections in the Control CC 74. If the values (d-coordinates in this case) User-Defined Flag is set to "false", the Default Storage System 420 will store the Selections Matrix 400 of the Control CC 74.
- a Text CC 76 is used to enter text strings.
- the Text CC 80 consists of a collection of characters such as 'U', 'S' or '$'. There are also control characters, such as LF (line feed) to indicate a line is over and FF (form feed) to indicate a page is over.
- LF line feed
- FF form feed
- a id text is one list of characters (a line), whereas a 2d text is a list of list of characters (a page), and so on. On any dimension, insertion and deletion are possible. Control characters are used to switch to the next unit in a given dimension. LF switches to the next unit in dimension 1 (a switch to the next line) and FF switches to the next unit in dimension 2 (a switch to the next page).
- the Maximal Length 460 set at Initialization time, is a number indicates the maximal character count for all texts in the Values Matrix. The number of characters in any Text CC 76 text value will never exceed the Maximal Length 460. However, if the Maximal Length 460 is set to -1, the text can have any length and the number of characters in the Text CC 80 can grow indefinitely.
- the Text View 465 entered at Initialization time, is a d-size specifying the number of characters rendered to the user on each text dimension. It can be considered as a view area, expressed in text character units.
- the Text View 465 must have the same number of dimensions than the text Number of Dimensions 455. It is used in the rendering process to define the dimensions of the displayed text component, especially when the Values (texts) Matrix has multiple dimensions.
- the Texts Matrix 450 (the Text CC 80 Values Matrix) holds all texts in the Text CC
- There is also a settext event that can be invoked from the end-user. It has the same parameters as settext(dnum pos, long lengthtoremove, char *string, long stringlength, dnum index dnumnull) 475.
- the Rendered UI is the concrete, 3D replica of the Conceptual User Interface
- CUI Device Components
- a DC is a tangible version of a linked CC (a CC accessible from the CUI) that uses for rendering specific, native components (NC's) that are proprietary to the device operating system such as, in Windows for example, an overlapped window, a push button, a checkbox, a dialog box, toolbar. Therefore, DCs are different from one platform to another.
- NC's native components
- the Rendered User Interface must fill the following tasks.
- a DC contrary to a CC, is not conceptual, and is truly rendered to the end-user using Conceptual Components (CCs). Many types are possible. There is always one associated DC for one linked CC, but its type is selected depending on the parent DC type and the CC attributes set at initialization time.
- the application logic When requested by the application logic, it takes device-specific events from the end-user and converts them into Conceptual Events sent to the corresponding CC, if applicable. All Conceptual Events are returned to and then processed by the application logic.
- the number of DC types can be extended to reflect different client contexts. For instance, in Windows, a Control CC with a 0-dimensioned states matrix can be rendered as a Menu Command DC or a Push Button DC, depending on the context (overlapped window menu or client window).
- the RUI makes the link between an abstract CUI and a specific platform user interface made of NCs. Therefore, its rules and links to device NCs must be coded once per platform by using platform-centric methods.
- a simple Calculator CUI 14 rendered with the Windows RUI 15 and the Output 1110 generated from the Windows RUI 15.
- the Calculator CUI 14 has only one element pushed in the Stack 62: a Container CC 72 that holds both the numeric display and the buttons matrix.
- the numeric display is a Text CC 76 with a 1- dimensioned text.
- the Control CC 74 contains the entire buttons matrix: its base d-size is ⁇ 4, 4 ⁇ (16 selections) among ⁇ states (1 state).
- the application logic is responsible for setting the matrix labels and modifing the numeric display when setselection conceptual events are received.
- the Windows RUI 15 is, for a Windows environment, a Modal window stack 1140 which is initially empty. When a CC tree is pushed in the Stack 12, the Windows RUI 15 will also push a Windows DC tree on the Modal window stack 1140.
- a CC of the CC tree Container CC 72, Text CC 76 and Control CC 74
- there is a corresponding DC in the DC tree Null DC 55, Edit DC 1150 and Button DC 1155.
- each DC in the tree is determined by examining the parent DC type and the CC attributes set at Initialization time. There is no parent DC type for the Container CC 72, so by default for containers, a Null DC 55 is created. Since the Null DC 55 has no frame, it creates one (an overlapped window 1160 in this case because it is the Root DC and the first pushed DC in the RUI - it would have been a modal dialog box otherwise) and removes it when it is destroyed. This frame reference will be passed to all children of the Null DC 55.
- the Edit DC 1150 associated to Text CC 76, contains a matrix of Edit controls. Since the values matrix d-size is ⁇ , there will be only one Edit control in the matrix. This Edit control will have as parent window the overlapped window 1160 sent by Null DC 55.
- the Button DC 1155 associated to Control CC 74, contains a matrix of Button controls with style Pushbutton.
- the values matrix is ⁇ 4, 4 ⁇ , allowing 16 selections within a state matrix of d-size ⁇ (1 state).
- the pushbutton Within an overlapped window, the only child control allowing a state change from ⁇ to ⁇ is the pushbutton. When it is pressed, it triggers the setselection( ⁇ , index within ⁇ 4, 4 ⁇ ) event.
- These pushbuttons will have as parent window the overlapped window 1160 sent by Null DC 55.
- DCs Device Components
- CCs Conceptual Componentes
- NCs Native Components
- Any DC performs an implementation of a logical use case of NCs. For example, it is logical in Windows to create a dialog box, then child controls within the dialog box. It is not logical, even if it is technically possible, to create an edit child confrol within a push button child control.
- the set of DC types is created to ensure logical combinations of NCs, to manage logical usage of the targeted platform UI, when rendering a CC tree.
- the steps required to render a CC tree in the CUI 14 stack begin by creating the Device Component tree in the RUI 15 stack.
- a Device Component (DC) 55 in the RUI 15 For each CC 60 in the CUI 14, a Device Component (DC) 55 in the RUI 15 must be initiated with a correct DC type. Since there can be many types of DCs 55, depending on the complexity of the platform user-interface, a set of DC decision flowcharts 1200 proprietary to the end-user device is required. Second, the DCs 55 in the RUI 15, according to their type, must generate all NCs 75 that form the rendered output. The passage from a DC 55 to NCs 75 is based on a set of NC decision flowcharts 1250 proprietary to the end-user device.
- a set of DC decision flowcharts 1200 and a set of NC decision flowcharts 1250 for the Windows platform provide a detailed example on how such flowcharts should be devised.
- the creation of a DC tree in the RUI 15 follows the top-down method, as opposed to the CC free in the CUI 14, created by the bottom-up approach. It means the Root DC 55 is created first, then its children, then its grandchildren, etc., following the tree structure of the corresponding CC tree from the CUI 14.
- the CC 60b to DC relationship is one-to-one.
- CCI 60a and CC2 60b are respectively associated to Device Components DCl 55a and DC2 55b according to the DC decision flowcharts proprietary to the client device.
- the DC to NC relationship is always one-to-many.
- NC Native Component
- the DCl 55a generates one NC
- NCI 75a the DC2 55b generates two NCs, NCI 75a and NC2 75b.
- NCs can be reused by more than one DC type.
- NCI 75a is used by both DCl 55a and DC2 55b.
- native set components are made of 0 to many called native components types here (native widget types), to accommodate DCs if a single NC is not sufficient (for instance, a Text CC with one value would have one NSC made of two NC, a static label and an Edit field).
- native component types are rendered to a certain type of user, which depends on the nature of the application.
- the object relationship is different from the type relationship.
- the program logic may generate as many CCs as required. However, as we've seen, there is one DC object for each CC object so the DC tree has the same topology as the CC tree. DCs may generate many NSCs, which in turn can generate many native components, presented to the user. By strictly following the type-object relationship in any rendering implementation, and the guidelines described below (using Windows as an example target device) to identify and implement DCs and NCs, a programmer implementing such rendering will save a lot of hassles. [0170] Any set of DC types can be organized in a state machine to illustrate the creation order of DCs when generating DC trees.
- the Windows state machine 1300 represents Windows DC types such as Tab Control 1365, Menu Command 1430 and Overlapped Window 1325. All states are terminal states, except for the states in italic (Start 1305, Menu bar Creation 1400, Status bar Creation 1450, Confrol Creation 1350 and Submenu Creation 1500) which are transitory states. The construction of a DC free from a CC tree will follow this state machine and always begins at Start 1305. Depending on the Root CC, a transition will be made either to Control Creation 1350 or Overlapped Window 1325. If the transition is made to Control Creation 1350, another fransition is immediately required to determine the DC type of the Root CC, since Control Creation 1350 is transitory.
- All states are terminal states, except for the states in italic (Start 1305, Menu bar Creation 1400, Status bar Creation 1450, Confrol Creation 1350 and Submenu Creation 1500) which are transitory states.
- the construction of a DC free from a CC tree will follow this state machine and always begins at Start 1305.
- This fransition will end to one of many DC types, such as Combo Box 1375 or Unlabeled Confrol 1390. Then, for children of the Root CC, other transitions begin from the current state.
- the state machine 1300 can be applied to all CCs of a CC tree, allowing the construction of the DC tree.
- the state machine 1300 rules for all transition are detailed in Figure 23A to Figure 23H flowcharts.
- the menu bar item construction flowchart verifies if the CC is qualified to become a menu bar item.
- the CC In order to qualify, the CC must not be a Text CC, must be 0-dimensioned and constantly read-only. If the CC is a Confrol CC, its states matrix must either be 0-dimensioned (generating a Menu Command DC) or 1-dimensioned, along the depth, with labels (generating a Menu Selection DC). If the CC is a Container CC, there must be children aligned on the depth direction. In this case, a Submenu DC is generated. Any other kind of CC is assumed to build a corresponding DC which type is linked to the overlapped window status bar.
- the status bar item construction flowchart verifies if the CC is qualified to become a status bar item.
- the CC must not be a Container CC, must be 0-dimensioned, not constantly read-only and having a string label.
- the DC generated is a Status Control DC, where only the current selected state is displayed in the status bar, besides the label if any.
- the CC is a Text CC, the text number of dimensions must be less than or equal to 1 (a line or a single character). If so, a Status Line DC is generated. Any other kind of CC is assumed to build a corresponding DC which type is linked to the overlapped window client rectangle, where child controls take place.
- the submenu item construction flowchart has almost the same behavior as the menu bar item construction flowchart from Figure 23C.
- the main exception is to allow 1-dimensioned CCs to become submenu items, as long as the dimension constant flag is false, aligned on the depth direction and has labels.
- Figure 23F there is another exception that happens when the states are unlabeled, constant and their number is 2 (generating a Menu Checkbox DC). Any other kind of CC is assumed to build a corresponding DC which type is linked to the overlapped window status bar in Figure 23E or to the overlapped window client rectangle in Figure 23F.
- the child control construction flowchart verifies if the CC is qualified to become a child confrol CC.
- the DC will be either Null DC, Tab Control DC, Edit DC, Push button DC, Combo Box DC, List Box DC, Radio Buttons DC or Unlabeled Control DC.
- Any other kind of CC cannot logically be constructed using child controls and is assumed to build a corresponding DC which type is generic.
- Generic DCs can render any CC and consequently are the DC typing bottom line that ensures the correct mapping of any CC tree for any platform, as explained in the next section.
- Figure 23H it is shown than a Generic DC can only contain other Generic DCs.
- NCs Windows Native Components
- NCs are created for all units of DC base d-size, in accordance with CUI rules regarding Values Matrix.
- Windows toolbar items are created along with menu items when bitmapped labels are defined, to allow direct access to options.
- the appropriate status bar parts NCs are created for Status Confrol and Status Line DCs. Since these DCs always have a 0-dimensioned Values Matrix, there is no need to loop through all base d-size units, which simplifies their NC creation flowcharts.
- FIG. 24C and Figure 24D the NC creation flowcharts related to all child control DCs are displayed. Since all these DCs can have a Values Matrix that has dimensions, parsing through all Values Matrix units is required for creating NCs. Furthermore, for most DCs, the method createlabelNCs, detailed in Figure 24E, has to be called to create label-related NCs such as static controls, dialog boxes, ... The createNCs(Unlabeled Control DC) from Figure 24D also shows that unlabeled controls have one anonymous selection child control per states matrix dimension, where the combination of child controls values form the selection (as shown in Figure 11).
- FIG. 26 a simple navigation example shows a Blackberry capable of displaying only one Children Set of a Container CC at a time.
- the screen title has the Container CC 72a label
- fields are labeled from the Text CC 76a, the Text CC 76b and the Text CC 76c and a menu option is taken from Container CC 72b.
- the end-user in order to navigate down to view 1600b, must select in the Blackberry menu the Container CC 72b label.
- the screen title label is extracted form Container CC 72b and all fields and menu options are modified to reflect view 1600b in the Blackberry 1610b.
- the Blackbe ⁇ y menu will always have an extra "Close” option in order to go back from view 1600b to view 1600a.
- all principles and techniques that have been used in the Windows example namely the state machine composed of DCs, the DC tree construction algorithm and the NC construction algorithms (all algorithms illustrated using flowcharts in this document) are equally applicable to the Blackberry and to any other platform.
- a fast layout algorithm is desirable for Graphical User Interface (GUI) renderings to correctly arrange the different widgets within windows and dialog boxes.
- GUI Graphical User Interface
- the input is a set of rectangles (Device Components in this case), comprising widgets, organized in a tree structure. With respect to the tree structure, it is desirable to position the rectangles adequately.
- the reading order of the tree elements is important (e.g. in a tree with two leaves A and B, then, B can be positioned below or right of A in order to see A first, then B, but B cannot be put first, then A below or right).
- a rectangle R is composed of a width, a height (in pixels in this case, both greater than or equal to 0) and a type (button, list box, etc.).
- the notation w(R) expresses the width of rectangle R and h(R) expresses the height of R.
- Both operators are commutative (A
- B B
- C) (A
- C A I B I C).
- (B - C) is not equal to (A
- a tree unit is, according to the legend, a binary node that has on its left side v the rectangle the unit is linked to (a, b or c in our example, not d as we will realize) and on its right side x another free unit which varies along parses.
- the set of flowcharts from Figure 29A to Figure 29N contains an implementation of this layout parsing.
- the layout parsing is associated with three data types.
- the Area type is the area of a rectangle, consisting of a width and a height, greater than or equal to 0.
- the Surface Component (SC) is a DC. In fact, all SCs are DCs, but not all DCs are SCs.
- a Button DC is an SC, but a Menu Command DC is not a SC. This is why an SC has its separate system for pointing its SC children, with NumSCs (number of SC children) and a Child SC set.
- the Surface area contains the overall surface of the DC array of NCs and is assumed, as for the previously introduced data members, to be initialized correctly before executing the layout algorithm.
- Three data members are going to be modified by the algorithm: Accumulated Surface, Offset and Op. They are used by the layout algorithm to "save" the best parenthesis combination and the accumulated surfaces of the combination.
- a Unit is a free unit like the ones shown in Figure 27.
- the Unit therefore contains SC, which is a reference to the parent SC that contains child SCs to be laid out, Pos is the index of its corresponding SC (at the right end of the tree unit), Op is the tree unit operator, TopUnit is a reference to the Unit that corresponds to SC (in case we have a tree of SCs which has more than one level), NextUnit is a reference to the right Unit in the binary tree and Surface is the accumulated surface of the surfaces of the left and right Units.
- SC is a reference to the parent SC that contains child SCs to be laid out
- Pos is the index of its corresponding SC (at the right end of the tree unit)
- Op is the tree unit operator
- TopUnit is a reference to the Unit that corresponds to SC (in case we have a tree of SCs which has more than one level)
- NextUnit is a reference to the right Unit in the binary tree
- Surface is the accumulated surface of the surfaces of the left and right Units.
- the main method getLayout(ParentSC, Pos) returns the best layout for displaying the SC (and its child SCs) pointed to by ParentSC and Pos.
- the layout Evaluator is reinitialised, as will be detailed below.
- the method doUnit is called, which does all the layout parsing and returns "true” if the best layout has been found, "false” otherwise (it should always return "true”).
- This value is returned to the caller of getLayout(ParentSC, Pos).
- the return value always is "true” when, after executing the method, a better layout has been found, and "false” otherwise.
- the method doUnit(SC, Pos, TopUnit, NextUnit) creates a new unit for the corresponding SC pointed to by its parameter parent SC at position Pos.
- SC Computed Standard
- Pos the SC
- Pos the SC
- TopUnit the SC
- NextUnit data members
- the doUnit method initializes the SC, Pos, TopUnit and NextUnit data members with the respective parameters of the method and simply calls processUnit(Unit) before deleting it.
- the return value will be the one returned by the call to processUnit(Unit).
- the processUnit(Unit) method is used to handle frees of SCs. It checks if the Unit corresponding SC has itself child SCs. If so, it must recursively process all possible sub-layouts of the corresponding SC by recalling doUnit for the child SC. Otherwise, there is only one corresponding SC area which is immediately returned by calling reportUnit(Unit, child SC surface).
- the reportUnit(Unit, Surface) method assigns a surface to the Unit parameter. Then, if the Unit Pos is greater than 0 (not the first child SC), the iteration process begins by calling accumulateUnit(Unit, NULL) (the NULL parameter specifies there is no left Unit pointed to by the current Unit).
- accumulateUnit(Unit, LeftUnit) is a method that sets correct operators to the Unit and saves its previous accumulation (if there is one) if any operator setting has generated a new best layout.
- TempFlag is used to determine between the first and last accumulated child SC to store the accumulation, due to a minimal (but efficient) accumulation storage system that is deciphered by the display algorithm to position widgets.
- Unit NextUnit operator to Op the current Unit Area and Unit NextUnit are saved and the accumulation with Unit Next Unit Surface is done (overwriting Unit Area).
- Unit NextUnit now points to Unit NextUnit NextUnit.
- we continue accumulations by recursively calling accumulateUnit(Unit, OldNextUnit) with the backed up Unit Next unit to tell accumulateUnit we have done an accumulation before calling it (and to save it if required). Then, we undo the accumulation by restoring the backed up Unit Area and Unit NextUnit.
- the processPreviousUnit(Unit) method does one verification, namely to see if there is actually more child SCs to create associated units.
- the current Unit Pos is compared to 0 (the first child SC position) and the Unit TopUnit existence is verified. If both conditions are true, then doUnit(Unit SC, Unit Pos - 1, Unit TopUnit, Unit) is called again to create a new Unit with the previous pos and the NextUnit parameter as the caller Unit. If we have reached the last element, we verify all Units Surfaces have been accumulated (by checking Unit NextUnit to NULL). If so, we have a layout for the child SC set to be processed accordingly.
- the save(SC, Surface, OuterPos, InnerPos, Op) method is called to store a surface accumulation that provided a new best layout.
- SC is the parent SC
- Surface is the accumulation result
- OuterPos is the index to store the accumulation
- InnerPos is the right area first index (the left area starts at InnerPos - 1).
- the child SC from SC at position OuterPos is retrieved and its Accumulated Surface and Offset are initialized to respectively Surface and InnerPos - OuterPos.
- the Op parameter is saved, this time in the child SC pointed to by SC and position InnerPos.
- Figure 291 to Figure 29N illustrate methods that are used throughout the parsing process.
- the accumulate(Surfacel, Surface!, Op) method accumulates Surface 1 and Surface2 with operator Op into Surface, according to the addition and maximum rules stated above, and returns Surface.
- the inverse(Op) method returns "vertical” if the Op parameter is "horizontal", and “horizontal” otherwise.
- the getDim(Surface, Op) returns the horizontal dimension (width) or vertical dimension (height) of Surface, depending on the Op parameter.
- the setDim(Surface, Op, Dim) sets to Dim the horizontal dimension (width) or vertical dimension (height) of Surface, depending on the Op parameter.
- the min(a, b) returns the minimum number between a and b.
- the max(a, b) returns the maximum number between a and b.
- the layout algorithm must be able to select the best layout among all the surfaces submissions from the parsing algorithm.
- a global object called Evaluator contains an InitFlag that must be set to "frue” before executing the layout parsing, a BestArea number which expresses, in square pixels the area of the best layout found, a MinimalArea which expresses, in square pixels the minimum area found (which may not be equal to BestArea) and BestFibo, which expresses the Fibonacci score (explained later) of the best layout found.
- the initEval(Evaluator) method simply resets the Evaluator InitFlag to "true", which is mandatory before parsing through all layouts. Referring to Figure 29A, it is therefore called by getLayout(ParentSC, Pos) before starting the parsing.
- the evalLayout(Evaluator, Surface) method is called to compare a new layout from the parsing to the previous best one found, to see if the new one is better. It first calculate Area, which is Surface expressed in square pixels. Then, it calculates the Phi Score by first calculating the ratio between the minimum area dimension and the maximum area dimension (on 1000). This ratio is then divided by the Phi number (618 if we're on a thousand base) and multiplied by 400 to end up with the Phi score.
- the final task of the Layout algorithm is to display the best layout found by the parsing algorithm using the evaluation method. At this time, the best layout is directly "saved" within SCs. Referring to Figure 28B, all SCs Accumulated Surface, Offset and Op have been set correctly and now contain the information we need to display the selected layout. [0220] Referring to Figure 31 A, the drawLayout(SC) method draws the specified layout for the SC tree which root is parameter SC.
- Pos is a Surface (width and height should be considered x and y in this case) which indicates the position of the first SC child of SC, which is (0, 0).
- Size is the SC Accumulated Surface.
- the positionSC(SC, Pos, Size) method sets the NC array of the DC SC at a specified Pos and Size with setSCPosition(SQ Pos) and setSCSize(SC, Size), which are not specified here since they depend on the target GUI platform. However, their ReturnCode is used so if one method fails, the layout drawing is stopped. If both return "true", positionSC does the inner layout if there are child SCs to arrange by calling positioh(SC, Pos, Size, 0, NumSCs).
- the Line type can be used to interpret binary layout data as lines.
- the Line data consists of a parent SC, the cu ⁇ ent element SC index, an offset to the next element, a limit (NumSCs) and the operator used between elements.
- the Line type needs methods to interact with.
- the f ⁇ rstUnit(Line, SC, Start, NumSCs) method initializes a Line object and make the internal Line data to point to the first element. Its SC and NumSCs are set to SC and NumSCs parameters. Then, we must initialize Index and Offset.
- the Start parameter is the index of the child SC that has the first offset.
- the boolean return value tells whether or not the element parsing within a line is over by testing NumSCs (the number of elements to parse) to 0. [0227] Referring to Figure 32B, the nextUnit(Line) method sets Line internal data to point to the next element (if there is one), from the cu ⁇ ent element. Line Index is simply incremented by Line Offset. Line NumSCs is decremented by Line Offset.
- Line NumSCs > 1
- the Operator is the same as Line Op (meaning the Line will continue the next time nextUnit(Line) is called)
- the Line Offset will point to the second element and nextUnit(Line) returns "false” to signify the line is not over. Otherwise, the Line Offset will be equal to NumSCs, which will force either this call (if NumSCs was already 0) or the next call to nextUnit(Line) to return "true”.
- the getUnitArea(Line) method returns the Surface of the cu ⁇ ent Line element. Since the element is itself a sub-line (that has a start and number of SCs), the method first retrieves the child SC at the sub-line start. Then, if the sub-line has more than one element (Line Offset always contains the sub-line number of SCs), then the returned element area will the child SC Accumulated Surface. If the sub-line has one element (one SC), we test if this child SC has children. If so, the returned Surface will be the Accumulated Surface of the first grandchild SC. If the child SC has no children, the child SC Surface will be returned.
- the getUnitStart(Line) method retrieves the sub-line Start parameter. It is always the index of the last SC in the sub-line, unless the sub- line is the last sub-line in the main line. In this case, the sub-line Start is the index of the first SC in the sub-line.
- the sub-line NumSCs is always equivalent to the cu ⁇ ent Line Offset, so it is blindly returned.
- the method position(SC, Pos, Size, Start, NumSCs) effectively does this task. It loops through the elements of the main line, and recursively calls itself within each element to sub-loop in sub-lines, until it reaches elements composed of a single SC. It first saves the Pos and Size parameters and assumes ReturnCode to be "true”. Then, it calculates the average space that will be inserted betweens elements of the cu ⁇ ent line. Then, it begins the loop that terminates when there are no more elements in the line or if something went wrong (ReturnCode would be "false” in this case).
- the getAvgSpace(SC, Size, Start, NumSCs) does a similar line loop to calculate the average space between elements in the line. It first ensures there are more than one element in the line (else, the returned average space is automatically 0). If so, the parsing is done with the variable Length adding the sizes of the elements for the Line Op dimension and incrementing NumAligned, which is the number of spaces in the line (line number of elements - 1 in fact). The returned average space will be the division of the total line allocated size minus Length by NumAligned.
- A, B, C be rectangles or combinations of rectangles.
- X (A
- (B - C)) at any time in the parsing algorithm and X' ((A
- A, B, C be rectangles or combinations of rectangles.
- Let X (A - (B
- C)) at any time in the parsing algorithm and X' (A - B). If w(X) is equal to w(X') and h(X) is equal to h(X'), then C has reached its upper limit for going up in the binary tree anymore for the operator
- C) become invalid. Conversely, let X (A
- (B - C)) at any time in the parsing algorithm and X' (A
- This law may put limits in shifting up a rectangle to the root of the binary free. It ensures that a rectangle totally included within two large rectangles is ideally positioned and cannot be moved anymore from this location.
- A, B, C be rectangles or combinations of rectangles.
- X ((A - B)
- X ((A
- B)) and X" ((A
- a set of generic DC will usually look like a table, or a matrix.
- the main task to build the generic DC table is to transform back and forth an abstract n-dimensional space such as a CC into a physical three-dimensional space that complies with the spatial nature of the universe.
- the 3D-number ⁇ 5, 3, 90 ⁇ refers to a 3D space of width 5, height 3 and depth 90.
- the method 3dnum getcapacity(dnum size, dirlist dirs) gives the 3D-size of any d- size (type 3dnum refers to 3D-numbers and type dirlist refers to a list of directions - w for width, h for height, d for depth - such as ⁇ w, w, d, h ⁇ , co ⁇ esponding to each dimension of size).
- type 3dnum refers to 3D-numbers
- type dirlist refers to a list of directions - w for width, h for height, d for depth - such as ⁇ w, w, d, h ⁇ , co ⁇ esponding to each dimension of size.
- a d-size associated with a direction list will be refe ⁇ ed to as a directional d-size.
- the method simply multiplies the values within size that have the same directions (for a direction never refe ⁇ ed to within dirs, value 1 is used).
- getcapacity( ⁇ 5, 4, 6, 2 ⁇ , ⁇ w, d, w, w ⁇ ) returns ⁇ 60, 1, 4 ⁇ and getcapacity( ⁇ , ⁇ ) returns ⁇ 1, 1, 1 ⁇ .
- the method 3dnum get3dcoord(dnum size, dnum index, dirlist dirs) gives the co ⁇ esponding 3d-coordinate of any d-coordinate within a d-size (for a direction never refe ⁇ ed to within dirs, value 0 is used).
- get3dcoord( ⁇ 3, 7 ⁇ , ⁇ 2, 3 ⁇ , ⁇ w, w ⁇ ) returns ⁇ 17, 0, 0 ⁇ ( ⁇ 2x7 + 3, 0, 0 ⁇ ).
- get3dcoord( ⁇ 5, 4, 6, 2 ⁇ , ⁇ 3, 1, 2, 0 ⁇ , ⁇ w, d, w, w ⁇ ) returns ⁇ 40, 0, 1 ⁇ ( ⁇ 3x6x2 + 2x2 + 0, 0, 1 ⁇ ).
- get3dcoord ( ⁇ , ⁇ , ⁇ ) returns ⁇ 0, 0, 0 ⁇ .
- the method 3dnum getndcoord(dnum size, 3dnum index, dirlist dirs) is the opposite of the latter function. It gives the co ⁇ esponding d-coordinate of any 3d-coordinate within a d- size (for a direction never refe ⁇ ed to within dirs, value 0 is used).
- getndcoord( ⁇ 5, 4, 6, 2 ⁇ , ⁇ 31, 0, 3 ⁇ , ⁇ w, d, w, w ⁇ ) returns ⁇ 2, 3, 3, 1 ⁇ . It will be understood that getndcoord ( ⁇ , ⁇ 0, 0, 0 ⁇ , ⁇ ) returns ⁇ .
- the base size of a CC is directional (with the directions parameter)
- the images are by their nature bi-directional (width x height)
- the children of Container CCs are also directional (with the children direction parameter)
- text dimensions in Text CCs are still directional (by default conventions)
- the CUI stack is also directional (throughout the depth axis)
- 3D accumulation 3 dnum 3dacc(3dnum sizes [], Direction dir). It is used to accumulate (or pack) different 3d-sizes across one specified direction. The result will be a 3 d-size that value across the direction will be the sum of all sizes values for the direction, and the two other values will be the maximal value of all sizes (just like Surface accumulation from the layout algorithm). For example, 3dacc( ⁇ 4, 5, 1 ⁇ , ⁇ 3, 2, 8 ⁇ , ⁇ 0, 4, 3 ⁇ , height) will return ⁇ 4, 11, 8 ⁇ . The 4 is the maximal width of all 3 sizes, the 11 is the sum of all heights and the 8 is the maximal depth of all sizes.
- the matrix view of a CC is the 3d-size of a rendered CC. It is usually different from one device to another, depending of the device characteristics (font size ). It is calculated from the multiplication of the CC base d-size capacity (according to the CC directions) and the element view, which is the 3D-size of a unit within the CC matrix (the calculation of element views is explained later). Mathematically, it is expressed as:
- Matrix view getcapacity(base d-size, directions) x Element view
- the Container CCs will take care of d- size accumulation in their own calculation of their element views.
- the interaction between the Matrix view and the Element view is presented schematically in Figure 20A.
- the element view of a CC is the 3d-size of one unit in the CC matrix. Its calculation, presented schematically in Figure 20B, depends on the CC type (Confrol, Text or Container), except when images are defined in the CC (if their width and height are greater than 0). In this case:
- Element view ⁇ image width, image height, 1 ⁇
- Element view ⁇ state string max length x character width, character height, 1 ⁇
- Element view ⁇ total digits x character width, character height, 1 ⁇
- the element view is the 3D accumulation of the matrix views (that must have been previously calculated by using a recursive algorithm parsing the CC tree) of the child CCs across the children direction:
- Element view 3dacc(children matrix views, children direction)
- the user view is a 3d-size, expressed in pixels, specifying the logical display, or what is immediately accessible by the end-user. For most devices, it is closely related to the display size. For example, in a 1600x1200 Windows screen, it can simply be ⁇ 1600, 1200, 1 ⁇ . However, since Windows computers can hold a lot of memory and consequently, can save much more information than what is displayed on a single screen, and since Windows makes an extensive use of the depth direction, it would be preferable to set it at say ⁇ 2400, 1800, 4 ⁇ (9 times bigger than ⁇ 1600, 1200, 1 ⁇ ).
- any part of the logical display can be shifted into it so the user can view all information.
- a reasonable user view would be ⁇ 200, 100, 1 ⁇ (the depth direction is not scarcely used in the Blackbe ⁇ y compared to more user-friendly environments such as Windows).
- the user view can be used to limit the number of values that are viewed at a time.
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Programmable Controllers (AREA)
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP03700775A EP1516247A2 (en) | 2002-02-01 | 2003-02-03 | Method and apparatus for designing, rendering and programming a user interface |
AU2003202377A AU2003202377A1 (en) | 2002-02-01 | 2003-02-03 | Method and apparatus for designing, rendering and programming a user interface |
CA002474750A CA2474750A1 (en) | 2002-02-01 | 2003-02-03 | Method and apparatus for designing, rendering and programming a user interface |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002369854A CA2369854A1 (en) | 2002-02-01 | 2002-02-01 | Conceptual interfacing technology |
CA2,369,854 | 2002-02-01 | ||
US38437502P | 2002-05-30 | 2002-05-30 | |
US60/384,375 | 2002-05-30 | ||
CA002388101A CA2388101A1 (en) | 2002-02-01 | 2002-05-30 | Conceptual user interface |
CA2,388,101 | 2002-05-30 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2003065191A2 true WO2003065191A2 (en) | 2003-08-07 |
WO2003065191A3 WO2003065191A3 (en) | 2004-08-12 |
Family
ID=27669576
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CA2003/000132 WO2003065191A2 (en) | 2002-02-01 | 2003-02-03 | Method and apparatus for designing, rendering and programming a user interface |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1516247A2 (en) |
AU (1) | AU2003202377A1 (en) |
WO (1) | WO2003065191A2 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014182495A1 (en) * | 2013-05-07 | 2014-11-13 | Axure Software Solutions, Inc. | Variable dimension version editing for graphical designs |
US9389759B2 (en) | 2013-05-07 | 2016-07-12 | Axure Software Solutions, Inc. | Environment for responsive graphical designs |
US9946806B2 (en) | 2013-05-07 | 2018-04-17 | Axure Software Solutions, Inc. | Exporting responsive designs from a graphical design tool |
US10592589B1 (en) | 2018-08-21 | 2020-03-17 | Axure Software Solutions, Inc. | Multi-view masters for graphical designs |
CN111176772A (en) * | 2019-12-24 | 2020-05-19 | 安克创新科技股份有限公司 | Method and device for state switching and robot |
CN113626900A (en) * | 2021-08-05 | 2021-11-09 | 复旦大学 | Facility asset icon generation method and system for road comprehensive rod system |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5327529A (en) * | 1990-09-24 | 1994-07-05 | Geoworks | Process of designing user's interfaces for application programs |
EP0622729A2 (en) * | 1993-04-29 | 1994-11-02 | International Business Machines Corporation | A user interface builder for a user interface server |
US5712993A (en) * | 1994-07-19 | 1998-01-27 | Sharp Kabushiki Kaisha | System for creating graphical user interfaces using changeable models for constituent parts |
US6343265B1 (en) * | 1998-07-28 | 2002-01-29 | International Business Machines Corporation | System and method for mapping a design model to a common repository with context preservation |
-
2003
- 2003-02-03 AU AU2003202377A patent/AU2003202377A1/en not_active Abandoned
- 2003-02-03 EP EP03700775A patent/EP1516247A2/en not_active Withdrawn
- 2003-02-03 WO PCT/CA2003/000132 patent/WO2003065191A2/en not_active Application Discontinuation
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5327529A (en) * | 1990-09-24 | 1994-07-05 | Geoworks | Process of designing user's interfaces for application programs |
EP0622729A2 (en) * | 1993-04-29 | 1994-11-02 | International Business Machines Corporation | A user interface builder for a user interface server |
US5712993A (en) * | 1994-07-19 | 1998-01-27 | Sharp Kabushiki Kaisha | System for creating graphical user interfaces using changeable models for constituent parts |
US6343265B1 (en) * | 1998-07-28 | 2002-01-29 | International Business Machines Corporation | System and method for mapping a design model to a common repository with context preservation |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014182495A1 (en) * | 2013-05-07 | 2014-11-13 | Axure Software Solutions, Inc. | Variable dimension version editing for graphical designs |
US9389759B2 (en) | 2013-05-07 | 2016-07-12 | Axure Software Solutions, Inc. | Environment for responsive graphical designs |
US9703457B2 (en) | 2013-05-07 | 2017-07-11 | Axure Software Solutions, Inc. | Variable dimension version editing for graphical designs |
US9946806B2 (en) | 2013-05-07 | 2018-04-17 | Axure Software Solutions, Inc. | Exporting responsive designs from a graphical design tool |
US10769366B2 (en) | 2013-05-07 | 2020-09-08 | Axure Software Solutions, Inc. | Variable dimension version editing for graphical designs |
US11409957B2 (en) | 2013-05-07 | 2022-08-09 | Axure Software Solutions, Inc. | Variable dimension version editing for graphical designs |
US10592589B1 (en) | 2018-08-21 | 2020-03-17 | Axure Software Solutions, Inc. | Multi-view masters for graphical designs |
US11068642B2 (en) | 2018-08-21 | 2021-07-20 | Axure Software Solutions, Inc. | Multi-view masters for graphical designs |
US11550988B2 (en) | 2018-08-21 | 2023-01-10 | Axure Software Solutions, Inc. | Multi-view masters for graphical designs |
CN111176772A (en) * | 2019-12-24 | 2020-05-19 | 安克创新科技股份有限公司 | Method and device for state switching and robot |
CN111176772B (en) * | 2019-12-24 | 2022-07-01 | 安克创新科技股份有限公司 | Method and device for state switching and robot |
CN113626900A (en) * | 2021-08-05 | 2021-11-09 | 复旦大学 | Facility asset icon generation method and system for road comprehensive rod system |
Also Published As
Publication number | Publication date |
---|---|
EP1516247A2 (en) | 2005-03-23 |
AU2003202377A1 (en) | 2003-09-02 |
WO2003065191A3 (en) | 2004-08-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7441200B2 (en) | Method and apparatus for designing, rendering and programming a user interface | |
US8875032B2 (en) | System and method for dynamic configuration of components of web interfaces | |
US7934162B2 (en) | Running state migration of platform specific graphical user interface widgets between heterogeneous device platforms | |
EP0712513B1 (en) | Graphic editor framework system | |
JP4381709B2 (en) | server | |
US7392483B2 (en) | Transformation of platform specific graphical user interface widgets migrated between heterogeneous device platforms | |
US5621434A (en) | Cursor manipulation system and method | |
US6330659B1 (en) | Hardware accelerator for an object-oriented programming language | |
US6983357B2 (en) | Hardware accelerator for an object-oriented programming language | |
US5793368A (en) | Method for dynamically switching between visual styles | |
US7234111B2 (en) | Dynamic adaptation of GUI presentations to heterogeneous device platforms | |
US20030063120A1 (en) | Scalable graphical user interface architecture | |
EP0622729A2 (en) | A user interface builder for a user interface server | |
US20030081007A1 (en) | Object oriented explorer type environment | |
US5479589A (en) | Object-oriented system for selecting a graphic image on a display | |
US5790132A (en) | Image rendering system with extensible mechanism for providing visual user feedback when an image graphic is selected | |
EP1516247A2 (en) | Method and apparatus for designing, rendering and programming a user interface | |
Grolaux et al. | FlexClock, a Plastic Clock Written in Oz with the QTk toolkit. | |
CA2474750A1 (en) | Method and apparatus for designing, rendering and programming a user interface | |
Banavar et al. | Tooling and system support for authoring multi-device applications | |
Carr et al. | Using interaction object graphs to specify graphical widgets | |
Reiss et al. | The Brown Workstation Environment | |
Rathnam et al. | User interface management systems: themes and variations a review of the literature | |
Uotila | A User Interface Toolkit for a Small Screen Device. | |
Loffredo | An X11 Graphics Extension for the ROSE Database System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2474750 Country of ref document: CA |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2003700775 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2003700775 Country of ref document: EP |
|
NENP | Non-entry into the national phase in: |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |