U.S. patent application number 15/203670 was filed with the patent office on 2017-04-27 for visual form designer.
This patent application is currently assigned to Oracle International Corporation. The applicant listed for this patent is Oracle International Corporation. Invention is credited to Laurensius Lie, George Thomas, Yue Zhou.
Application Number | 20170115864 15/203670 |
Document ID | / |
Family ID | 58558575 |
Filed Date | 2017-04-27 |
United States Patent
Application |
20170115864 |
Kind Code |
A1 |
Thomas; George ; et
al. |
April 27, 2017 |
VISUAL FORM DESIGNER
Abstract
A visual form designer is disclosed. A target user interface is
configured to display a particular form. A design user interface is
used to design the target user interface. The target user interface
includes an instance of an interface widget. A customizable widget
property of the interface widget is a set of selectable values for
the interface widget. As an example, the interface widget may be a
dropdown menu for accepting one of a set of selectable values. The
design user interface displays multiple existing data sources. Each
data source specifies a limited set of selectable values. The
design user interface receives user input selecting one of the data
sources. The instance of the interface widget is configured to
accept a value from the limited set of selectable values specified
by the selected data source. Hence, the instance of the interface
widget is integrated with the selected data source.
Inventors: |
Thomas; George; (San Ramon,
CA) ; Zhou; Yue; (Dublin, CA) ; Lie;
Laurensius; (Castro Valley, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Oracle International Corporation |
Redwood Shores |
CA |
US |
|
|
Assignee: |
Oracle International
Corporation
Redwood Shores
CA
|
Family ID: |
58558575 |
Appl. No.: |
15/203670 |
Filed: |
July 6, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62245991 |
Oct 24, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 8/38 20130101; G06F
3/04817 20130101; G06F 3/04842 20130101; G06F 3/0482 20130101; G06F
3/04847 20130101 |
International
Class: |
G06F 3/0484 20060101
G06F003/0484; G06F 3/0481 20060101 G06F003/0481; G06F 9/44 20060101
G06F009/44; G06F 3/0482 20060101 G06F003/0482 |
Claims
1. A non-transitory computer readable medium comprising
instructions which, when executed by one or more hardware
processors, causes performance of operations comprising:
concurrently displaying a widget-selection section, a form-design
section, and a widget-properties section; displaying available
interface widgets, for designing a particular form, in the
widget-selection section; responsive at least to receiving a first
user input dragging a first interface widget from the
widget-selection section to the form-design section: concurrently
displaying (a) an instance of the first interface widget in the
form-design section and (b) a set of customizable widget properties
corresponding to the instance of the first interface widget in the
widget-properties section, wherein the instance of the first
interface widget is associable with at least one of a plurality of
existing data sources, wherein each of the plurality of existing
data sources specifies a respective set of values; displaying a
list comprising the plurality of existing data sources; responsive
to receiving a second user input that (a) is received via the
widget-properties section, (b) selects at least one of the
plurality of existing data sources, and (c) is in relation to the
instance of the first interface widget: configuring the instance of
the first interface widget for accepting a value from the set of
values specified by the selected existing data source.
2. The medium of claim 1, wherein the operations further
comprising: responsive to receiving a third user input selecting a
particular destination for the first interface widget: mapping the
data submission, received via the first interface widget, to
storage at the particular destination.
3. The medium of claim 1, wherein the operations further comprise:
receiving a third user input selecting a sequence of users for
approving a request submitted via the particular form; subsequent
to receiving a first request from a first user via the particular
form: selecting a second user for approving the first request from
the selected sequence of users; and displaying the first request to
the second user.
4. The medium of claim 1, wherein the operations further comprise:
receiving a third user input selecting a subset of users that have
permission to submit a request via the particular form; subsequent
to receiving a first request from a first user to display the
particular form: responsive to determining that the first user is
not included in the selected subset of users, refraining from
displaying the particular form to the first user.
5. The medium of claim 1, wherein the operations further comprise:
receiving a third user input selecting a subset of users that do
not have permission to submit a request via the particular form;
subsequent to receiving a first request from a first user to
display the particular form: responsive to determining that the
first user is included in the selected subset of users, refraining
from displaying the particular form to the first user.
6. The medium of claim 1, wherein the operations further comprise:
receiving a third user input selecting a subset of users that have
permission to submit a request via the particular form; receiving a
fourth user input selecting a sequence of users for approving a
request submitted via the particular form; subsequent to receiving
a first request from a first user to display the particular form:
responsive to determining that the first user is included in the
selected subset of users, displaying the particular form to the
first user: selecting a second user for approving the first request
from the selected sequence of users; and displaying the first
request to the second user.
7. The medium of claim 1, wherein the operations further comprise:
receiving a third user input selecting a particular landing page
for displaying an icon representing the particular form; subsequent
to receiving a first request from a first user to display the
particular landing page: responsive to determining that the
particular landing page is selected for displaying the icon
representing the particular form based on the third user input,
displaying the icon representing the particular form on the
particular landing page.
8. The medium of claim 1, wherein: the selected existing data
source is organized according to a schema associated with a set of
data fields; and a particular data field, of the set of data
fields, stores the set of values.
9. The medium of claim 1, wherein the operations further comprise:
subsequent to receiving a first request from a first user to
display the particular form: identifying the set of values
currently stored by the selected existing data source; displaying
the set of values currently stored by the selected existing data
source; and accepting user input selecting one of the set of values
currently stored by the selected existing data source.
10. A system, comprising: at least one device including a hardware
processor; and the system configured to perform operations
comprising: concurrently displaying a widget-selection section, a
form-design section, and a widget-properties section; displaying
available interface widgets, for designing a particular form, in
the widget-selection section; responsive at least to receiving a
first user input dragging a first interface widget from the
widget-selection section to the form-design section: concurrently
displaying (a) an instance of the first interface widget in the
form-design section and (b) a set of customizable widget properties
corresponding to the instance of the first interface widget in the
widget-properties section, wherein the instance of the first
interface widget is associable with at least one of a plurality of
existing data sources, wherein each of the plurality of existing
data sources specifies a respective set of values; displaying a
list comprising the plurality of existing data sources; responsive
to receiving a second user input that (a) is received via the
widget-properties section, (b) selects at least one of the
plurality of existing data sources, and (c) is in relation to the
instance of the first interface widget: configuring the instance of
the first interface widget for accepting a value from the set of
values specified by the selected existing data source.
11. The system of claim 10, wherein the operations further
comprising: responsive to receiving a third user input selecting a
particular destination for the first interface widget: mapping the
data submission, received via the first interface widget, to
storage at the particular destination.
12. The system of claim 10, wherein the operations further
comprise: receiving a third user input selecting a sequence of
users for approving a request submitted via the particular form;
subsequent to receiving a first request from a first user via the
particular form: selecting a second user for approving the first
request from the selected sequence of users; and displaying the
first request to the second user.
13. The system of claim 10, wherein the operations further
comprise: receiving a third user input selecting a subset of users
that have permission to submit a request via the particular form;
subsequent to receiving a first request from a first user to
display the particular form: responsive to determining that the
first user is not included in the selected subset of users,
refraining from displaying the particular form to the first
user.
14. The system of claim 10, wherein the operations further
comprise: receiving a third user input selecting a subset of users
that do not have permission to submit a request via the particular
form; subsequent to receiving a first request from a first user to
display the particular form: responsive to determining that the
first user is included in the selected subset of users, refraining
from displaying the particular form to the first user.
15. The system of claim 10, wherein the operations further
comprise: receiving a third user input selecting a subset of users
that have permission to submit a request via the particular form;
receiving a fourth user input selecting a sequence of users for
approving a request submitted via the particular form; subsequent
to receiving a first request from a first user to display the
particular form: responsive to determining that the first user is
included in the selected subset of users, displaying the particular
form to the first user: selecting a second user for approving the
first request from the selected sequence of users; and displaying
the first request to the second user.
16. The system of claim 10, wherein the operations further
comprise: receiving a third user input selecting a particular
landing page for displaying an icon representing the particular
form; subsequent to receiving a first request from a first user to
display the particular landing page: responsive to determining that
the particular landing page is selected for displaying the icon
representing the particular form based on the third user input,
displaying the icon representing the particular form on the
particular landing page.
17. The system of claim 10, wherein: the selected existing data
source is organized according to a schema associated with a set of
data fields; and a particular data field, of the set of data
fields, stores the set of values.
18. The system of claim 10, wherein the operations further
comprise: subsequent to receiving a first request from a first user
to display the particular form: identifying the set of values
currently stored by the selected existing data source; displaying
the set of values currently stored by the selected existing data
source; and accepting user input selecting one of the set of values
currently stored by the selected existing data source.
19. A method, comprising: concurrently displaying a
widget-selection section, a form-design section, and a
widget-properties section; displaying available interface widgets,
for designing a particular form, in the widget-selection section;
responsive at least to receiving a first user input dragging a
first interface widget from the widget-selection section to the
form-design section: concurrently displaying (a) an instance of the
first interface widget in the form-design section and (b) a set of
customizable widget properties corresponding to the instance of the
first interface widget in the widget-properties section, wherein
the instance of the first interface widget is associable with at
least one of a plurality of existing data sources, wherein each of
the plurality of existing data sources specifies a respective set
of values; displaying a list comprising the plurality of existing
data sources; responsive to receiving a second user input that (a)
is received via the widget-properties section, (b) selects at least
one of the plurality of existing data sources, and (c) is in
relation to the instance of the first interface widget: configuring
the instance of the first interface widget for accepting a value
from the set of values specified by the selected existing data
source; wherein the method is performed by a device including a
hardware processor.
20. The method of claim 19, further comprising: responsive to
receiving a third user input selecting a particular destination for
the first interface widget: mapping the data submission, received
via the first interface widget, to storage at the particular
destination.
Description
BENEFIT CLAIM; INCORPORATION BY REFERENCE
[0001] This application claims the benefit of U.S. Provisional
Patent Application 62/245,991, filed Oct. 24, 2015, which is hereby
incorporated by reference.
TECHNICAL FIELD
[0002] The present disclosure relates to designing an interface. In
particular, the present disclosure relates to providing an
application which can be used by a user to design an interface
without the user programming the interface with a programming
language.
BACKGROUND
[0003] A form provides a standardized format for submitting
requests, orders, and/or other information. Different companies may
use different forms for submitting different requests. As an
example, Company A may offer reimbursement of tuition expenses for
courses taken by employees. Company A may require identification of
the course by course number. Company A may utilize a form, for
submitting tuition reimbursement requests, that includes a field
accepting the course number. Company B may also offer reimbursement
of tuition expenses for courses taken by employees. Company B may
require a textual description of the course. Company B may utilize
a form, for submitting tuition reimbursement requests, that
includes a field accepting the textual description of the course.
As illustrated in this example, Company A and Company B use
different forms for submitting tuition reimbursement requests.
[0004] A form includes various fields for accepting specific types
of data. Different types of fields may be used, such as a textbox,
a dropdown menu, a toggle button, and/or a checkbox. Different
companies may design different forms, including different fields,
for submitting requests.
[0005] The approaches described in this section are approaches that
could be pursued, but not necessarily approaches that have been
previously conceived or pursued. Therefore, unless otherwise
indicated, it should not be assumed that any of the approaches
described in this section qualify as prior art merely by virtue of
their inclusion in this section.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The embodiments are illustrated by way of example and not by
way of limitation in the figures of the accompanying drawings. It
should be noted that references to "an" or "one" embodiment in this
disclosure are not necessarily to the same embodiment, and they
mean at least one. In the drawings:
[0007] FIG. 1A illustrates an interface design system, in
accordance with one or more embodiments;
[0008] FIG. 1B illustrates an example of a design user interface,
in accordance with one or more embodiments;
[0009] FIG. 2 illustrates an example set of operations for
configuring a widget property for a particular form, in accordance
with one or more embodiments;
[0010] FIG. 3 illustrates an example set of operations for
configuring a form property for a particular form, in accordance
with one or more embodiments;
[0011] FIG. 4 illustrates an example set of operations for
receiving a request via a particular form, in accordance with one
or more embodiments;
[0012] FIGS. 5A-5I illustrate example screenshots of a design user
interface for designing a particular form, in accordance with one
or more embodiments;
[0013] FIGS. 6A-6C illustrate example screenshots for submitting a
request via a particular form, in accordance with one or more
embodiments;
[0014] FIG. 7 illustrates an example of a destination that is
shared by two forms, in accordance with one or more embodiments;
and
[0015] FIG. 8 shows a block diagram that illustrates a computer
system in accordance with one or more embodiments.
DETAILED DESCRIPTION
[0016] In the following description, for the purposes of
explanation, numerous specific details are set forth in order to
provide a thorough understanding. One or more embodiments may be
practiced without these specific details. Features described in one
embodiment may be combined with features described in a different
embodiment. In some examples, well-known structures and devices are
described with reference to a block diagram form in order to avoid
unnecessarily obscuring the present invention.
[0017] 1. GENERAL OVERVIEW
[0018] 2. INTERFACE DESIGN SYSTEM ARCHITECTURE
[0019] 3. CONFIGURING A WIDGET PROPERTY FOR A PARTICULAR FORM
[0020] 4. CONFIGURING A FORM PROPERTY FOR A PARTICULAR FORM
[0021] 5. RECEIVING A REQUEST VIA A PARTICULAR FORM
[0022] 6. EXAMPLE EMBODIMENTS
[0023] 7. MISCELLANEOUS; EXTENSIONS
[0024] 8. HARDWARE OVERVIEW
1. GENERAL OVERVIEW
[0025] One or more embodiments include a design user interface for
designing a target user interface displaying a particular form. The
particular form includes an instance of an interface widget that is
integrated with an existing data source. The design user interface
displays multiple existing data sources that may be associated with
the instance of the interface widget. Each data source specifies a
limited set of selectable values. A user designing the particular
form may select one of the multiple existing data sources. The
instance of the interface widget is configured to accept a value
from the limited set of selectable values specified by the selected
data source. The interface widget may be, for example, a dropdown
menu that accepts a value from the limited set of selectable
values.
[0026] One or more embodiments include a design user interface for
designing a target user interface displaying a particular form. The
particular form includes an instance of an interface widget that is
associated with a particular destination. The particular
destination is configured to store data submitted via the instance
of the interface widget. The design user interface displays
multiple destinations that may be configured to store data. A user
designing the particular form may select one of the multiple
destinations. Data submitted via the instance of the interface
widget is stored at the selected destination. Data submitted via
multiple instances of interface widgets may be stored at a same
destination or different destinations. Data submitted via different
forms may be stored at a same destination or different
destinations.
[0027] One or more embodiments include a design user interface for
specifying users and/or roles that are required for approving a
request submitted via a particular form. The design user interface
displays users and/or roles for selection. A user designing the
particular form may select a sequence of users and/or roles for
approving a request submitted via a particular form. Requests
submitted via the particular form are transmitted to each user
and/or role for approval.
[0028] One or more embodiments include a design user interface for
specifying users and/or roles that have permissions for submitting
a request via a particular form. The design user interface displays
users and/or roles for selection. A user designing the particular
form may select users and/or roles having permissions to the
particular form. The particular form may be displayed to users
and/or roles that are associated with the corresponding
permissions. The particular form is not displayed to users and/or
roles that are not associated with the corresponding
permissions.
[0029] One or more embodiments include a design user interface for
specifying a landing page configured to display an icon
representing the particular form. The design user interface
displays multiple landing pages for selection. Each landing page
may be associated with a different group of end users. A user
designing the particular form may select landing pages for
displaying an icon representing the particular form. The selected
landing pages are associated with the particular form. A particular
landing page may be displayed for a particular end user. If the
particular landing page is associated with the particular form,
then the particular landing page displays an icon representing the
particular form. The particular end user may select the icon to
request display of the particular form.
[0030] In one or more embodiments, the design user interface is a
graphical user interface (GUI) that includes multiple sections. A
widget-selection section, a form-design section, and a
widget-properties section are concurrently displayed. A user may
design a form using the design user interface, without programming
the target user interface using a programming language.
[0031] One or more embodiments described in this Specification
and/or recited in the claims may not be included in this General
Overview section.
2. INTERFACE DESIGN SYSTEM ARCHITECTURE
[0032] FIG. 1A illustrates an interface design system 100, in
accordance with one or more embodiments. As illustrated in FIG. 1A,
system 100 includes an interface design engine 102, a data
repository 104, a design user interface 106, and a target user
interface 108. In one or more embodiments, system 100 may include
more or fewer components than the components illustrated in FIG.
1A. The components illustrated in FIG. 1A may be local to or remote
from each other. The components illustrated in FIG. 1A may be
implemented in software and/or hardware. Each component may be
distributed over multiple applications and/or machines. Multiple
components may be combined into one application and/or machine.
Operations described with respect to one component may instead be
performed by another component.
[0033] In one or more embodiments, target user interface 108 is
configured to display a form used by an end user. A form provides a
standardized format for submitting requests, orders, and/or other
information. A form may be used to submit, for example, a tuition
reimbursement request, a vacation request, a food order, a
performance review, and/or a complaint. An end user may be, for
example, an employee of a particular company who wishes to submit a
request, order, and/or other information.
[0034] Target user interface 108 includes a graphical user
interface (GUI). A GUI enables communication and/or interaction
between a system and a user using visual user interface elements.
Target user interface 108 may optionally also include a command
line interface (CLI), a haptic interface, and a voice command
interface.
[0035] Target user interface 108 includes one or more interface
widgets 126 that are displayed by the GUI. An interface widget 126
is a user interface element or field for accepting data. Examples
of interface widgets 126 include a textbox, a dropdown menu, a
toggle button, a date selector, a number field, and/or a
checkbox.
[0036] In one or more embodiments, design user interface 106 is
configured to design a form. Design user interface 106 includes a
GUI. A user may design target user interface 108 using design user
interface 106, without programming target user interface 108 using
a programming language. A user may configure an interface widget
125 of target user interface 108 using design user interface 106,
without using a programming language. Examples of programming
languages include C, C++, Hypertext Markup Language (HTML),
JavaScript, Extensible Markup Language (XML), XML User Interface
Language (XUL), Cascading Style Sheets (CSS), and Java.
[0037] Design user interface 106 includes sections 124 displayed by
the GUI. Multiple sections may be concurrently displayed. Each
section 124 includes user interface elements associated with a
particular topic and/or category.
[0038] FIG. 1B illustrates an example of design user interface 106,
in accordance with one or more embodiments. Design user interface
106 concurrently displays widget-selection section 124a,
form-design section 124b, and widget-properties section 124c.
Additional and/or alternative sections 124 may be used.
[0039] Widget-selection section 124a displays interface widgets 126
that are available for selection by a user designing target user
interface 108. Form-design section 124b displays a form that is
being designed. The form being designed may include interface
widgets 126 that have been selected from the widget-selection
section 124a. As an example, a user designing a form may drop and
drop a particular interface widget from the widget-selection
section to the form-design section. The location at which the
particular interface widget is dropped is the location at which an
instance of the particular interface widget will be displayed on
the form.
[0040] Widget-properties section 124a displays customizable widget
properties 110 associated with an interface widget 126. Further
description relating to customizable widget properties 110 are
included below.
[0041] In one or more embodiments, data repository 104 is any type
of storage unit and/or device (e.g., a file system, database,
collection of tables, or any other storage mechanism) for storing
data. Further, data repository 104 may include multiple different
storage units and/or devices. The multiple different storage units
and/or devices may or may not be of the same type or located at the
same physical site. Further, data repository 104 may be implemented
or may execute on the same computing system as interface design
engine 102. Alternatively or additionally, data repository 104 may
be implemented or executed on a computing system separate from
interface design engine 102. Data repository 104 may be
communicatively coupled to interface design engine 102 via a direct
connection or via a network.
[0042] Information describing customizable widget properties 110
and customizable form properties 116 may be implemented across any
of components within system 100. However, this information is
illustrated within data repository 104 for purposes of clarity and
explanation.
[0043] In one or more embodiments, customizable widget property 110
is a property and/or characteristic of an interface widget 126 that
is configurable by a user designing target user interface 108.
Customizable widget property 110 may be a visual property of
interface widget 126, such as a color of interface widget 126, and
a size of interface widget 126. Additionally or alternatively,
customizable widget property 110 may be metadata associated with
interface widget 126. Metadata associated with interface widget 126
includes, for example, an identifier (ID) of interface widget 126,
a flag indicating whether interface widget 126 is a required field
of a form, a type of interface widget 126, and a location on a
particular form at which interface widget 126 is to be
displayed.
[0044] One example of a customizable widget property 110 associated
with an instance of a particular interface widget 126 is a set of
selectable values 114. The particular interface widget 126 is
configured to accept a value from the set of selectable values 114.
The particular interface widget 126 may not accept any value that
is not included in the set of selectable values 114. The particular
interface widget 126 may be, for example, a dropdown menu that
accepts a value from a set of selectable values 114.
[0045] The set of selectable values 114, associated with an
instance of a particular interface widget 126, is specified by one
of a plurality of existing data sources 112. As an example, a data
source may include a set of values: United States, Canada, Mexico.
An instance of a particular interface widget associated with the
data source may accept a value from the set of values: United
States, Canada, Mexico. The instance of the particular interface
widget may not accept values other than: United States, Canada,
Mexico.
[0046] Data source 112 is a database, record, log, table, list,
and/or other structure configured to store data. Additionally or
alternatively, data source 112 is a column, row, and/or cell of a
database. In an embodiment, different data sources 112 may be
different databases. In another embodiment, different data sources
112 may be different columns of a same database.
[0047] Data source 112 may be maintained by an application that is
separate from interface design engine 102. As an example, a data
source may include departments of a company. A particular
application for managing a corporate organizational structure may
be used to maintain the data source. The particular application may
be separate from an application for designing a form. However, the
application for designing a form has access to the data source.
[0048] Data source 112 may include information in addition to
selectable values for an instance of an interface widget 126. The
information stored by data source 112 may be organized according to
a schema. The schema may include various data fields, one of which
is configured to store selectable values for an instance of an
interface widget 126.
[0049] As an example, a schema for a data source may include the
following data fields: Department Name, and Department Head. A
first entry may include: "Sales Department" under Department Name,
and "John Smith" under Department Head. A second entry may include:
"Engineering Department" under Department Name, and "Elizabeth
Brown" under Department Head. A set of selectable values, for an
instance of a particular interface widget, may be specified by the
Department Name field of the data source. The set of selectable
values may be: "Sales Department," "Engineering Department."
[0050] Another example of a customizable widget property 110
associated with an instance of a particular interface widget 126 is
a destination for storing data submitted via the instance of the
particular interface widget 126. A destination is a database,
record, log, table, list, and/or other structure configured to
store data. Additionally or alternatively, a destination is a
column, row, and/or cell of a database. Data submitted via multiple
instances of interface widgets may be stored at a same destination
or different destinations. Data submitted via different forms may
be stored at a same destination or different destinations.
[0051] In an embodiment, multiple instances of interface widgets
may share a same destination. Instances of interface widgets of
different forms may share a same destination.
[0052] As an example, a system may include multiple forms. "Tuition
Reimbursement Form" may include the fields "Department" and
"Tuition Amount." "Vacation Request Form" may include the fields
"Start Date" and "Total Number of Days."
[0053] The multiple forms may share a particular table as a
destination. Each entry of the particular table may correspond to
different data submission made via one of the multiple forms.
[0054] A first column of the particular table may store a "Form
Name" corresponding to a particular entry. The "Form Name" may be
"Tuition Reimbursement Form" or "Vacation Request Form." A second
column may correspond to the "Department" field of the "Tuition
Reimbursement Form." A third column may correspond to the "Start
Date" field of the "Vacation Request Form." A fourth column may
correspond to both (a) the "Tuition Amount" field of the "Tuition
Reimbursement Form" and (b) the "Total Number of Days" field of the
"Vacation Request Form." As shown in this example, each column
corresponds to one instance of an interface widget of a particular
form. However, one column may correspond to multiple instances of a
same or different interface widget across different forms.
[0055] Additional and/or alternative customizable widget properties
110 may be used.
[0056] In one or more embodiments, customizable form property 116
is a property and/or characteristic of a form displayed by target
user interface 108. Customizable form property 116 is configurable
by a user designing target user interface 108. Customizable form
property 116 may be a visual property of the form, such as a title
of the form. Additionally or alternatively, customizable form
property 116 may be metadata associated with the form. Metadata
associated with the form includes, for example, a form ID.
[0057] One example of a customizable form property 116 is approval
settings 118. Approval settings 118 includes specification of a
group of users and/or roles that are required for approving a
request submitted via a particular form. A user may be identified
based on a user ID. A role may be a position, title, and/or other
categorization associated with one or more users. As an example, a
role may be "Chief Executive Officer." As another example, a role
may be "Any Member of the Sales Team."
[0058] Another example of a customizable form property 116 is
security settings 120. Security settings 120 includes specification
of a group of users and/or roles that have permissions to submit a
request via a particular form. Users and/or roles outside of the
security group may not submit a request via the particular
form.
[0059] Another example of a customizable form property 116 is
landing page settings 122. Landing page settings 122 includes
specification of one or more landing pages for displaying an icon
representing a particular form. A landing page is a user interface
that is displayed to an end user by a particular application. An
icon displayed by a landing page may be selected by an end user to
display another user interface.
[0060] A particular application may be associated with various
landing pages. Each landing page may be associated with a
particular topic and/or category. A landing page displays various
icons related to the particular topic and/or category. As an
example, one landing page may be associated with "Timesheets."
Another landing page may be associated "Benefits." The "Timesheets"
landing page may include an icon for a particular form. The form
may be used by an end user to submit time entries and request
overtime pay. The "Benefits" landing page may include an icon for
another form. The form may be used by an end user to claim health
benefits.
[0061] Each landing page is associated with a group of end users.
Different end users of the particular application have access to
different landing pages. As an example, an application may be
associated with multiple pages, including a particular landing page
titled "Bob's Team." The particular landing page may include items
that are useful for members of Bob's team. The particular landing
page may be associated with the end users John Smith and Mary
Jones. Various end users may utilize the application. Only John
Smith and Mary Jones have access to the particular landing page.
Other end users of the application do not have access to the
particular landing page.
[0062] Alternatively, a landing page is associated with a
particular set of roles. End users associated with at least one of
the particular set of roles have access to the landing page. As an
example, a "Timesheets" landing page may be associated with the
role "Non-Exempt Employee." Non-exempt employees may be entitled to
overtime pay and may be required to enter timesheets. Hence, an end
user who is a "Non-Exempt Employee" may have access to the
"Timesheet" landing page. An end user who is an "Exempt Employee"
does not have access to the "Timesheet" landing page.
[0063] Additional and/or alternative customizable form properties
116 may be used.
[0064] In one or more embodiments, interface design engine 102
refers to hardware and/or software configured to perform operations
described herein for designing target user interface 108 using
design user interface 106. Examples of operations for designing
target user interface 108 using design user interface 106 are
described below with reference to FIGS. 2-3.
[0065] In an embodiment, interface design engine 102 is implemented
on one or more digital devices. The term "digital device" generally
refers to any hardware device that includes a processor. A digital
device may refer to a physical device executing an application or a
virtual machine. Examples of digital devices include a computer, a
tablet, a laptop, a desktop, a netbook, a server, a web server, a
network policy server, a mainframe, a television, a content
receiver, a set-top box, a printer, a mobile handset, a smartphone,
and/or a personal digital assistant ("PDA").
3. CONFIGURING A WIDGET PROPERTY FOR A PARTICULAR FORM
[0066] FIG. 2 illustrates an example set of operations for
configuring a widget property for a particular form, in accordance
with one or more embodiments. One or more operations illustrated in
FIG. 2 may be modified, rearranged, or omitted all together.
Accordingly, the particular sequence of operations illustrated in
FIG. 2 should not be construed as limiting the scope of one or more
embodiments.
[0067] One or more embodiments include concurrently displaying a
widget-selection section, a form-design section, and a
widget-properties section, for designing a particular form
(Operation 202). An interface design engine displays a design user
interface. The design user interface includes concurrent display of
the widget-selection section, the form-design section, and the
widget-properties section. Concurrently displaying may include
displaying the multiple sections side-by-side on a design user
interface. Additionally or alternatively, concurrently displaying
may include displaying the multiple sections overlapping with each
other on a design user interface.
[0068] The interface design engine displays, in the
widget-selection section, interface widgets that are available for
selection. A user designing the particular form may select any of
the interface widgets in the widget-selection section for inclusion
in the particular form.
[0069] The interface design engine displays, in the form-design
section, a form template that may be used to design the particular
form. The form-design section may be configurable to present the
form template in various dimensions. A form template having
particular dimensions is suited for being displayed by devices
having a particular form factor. As an example, a form-design
section may include options for displaying the form template in
various dimensions. One option may provide that the ratio of the
width of the form template to the height of the form template is
16:9. This option may be suitable for laptops, which have screens
associated with a form factor of 16:9. Another option may provide
that the ratio of the width of the form template to the height of
the form template is 1:2. This option may be suitable for
smartphones, which have screens associated with a form factor of
1:2.
[0070] The interface design engine displays, in the
widget-properties section, customizable widget properties of one or
more instances of interface widgets that have been selected for
inclusion in the particular form.
[0071] One or more embodiments include receiving user input
dragging an interface widget from the widget-selection section to
the form-design section (Operation 204). The interface design
engine receives user input via the design user interface. The user
input comprises dragging an interface widget from the
widget-selection section and dropping the interface widget in the
form-design section. The interface design engine may receive user
input comprising dropping an interface widget at a particular
location in the form template displayed in the form-design
section.
[0072] One or more embodiments include concurrently displaying (a)
an instance of the interface widget in the form-design section and
(b) a set of customizable widget properties in the
widget-properties section (Operation 206). The interface design
engine generates and displays an instance of the interface widget.
The interface design engine displays the instance of the interface
widget at the particular location at which the interface widget was
dropped in the form-design section.
[0073] Additionally, the interface design engine identifies a set
of customizable widget properties associated with the interface
widget. The interface design engine displays the set of
customizable widget properties for the instance of the interface
widget in the widget-properties section. The set of customizable
widget properties may include: a label of the instance of the
interface widget, a description of the instance of the interface
widget, and/or an existing data source to be associated with the
instance of the interface widget.
[0074] One or more embodiments include displaying a list comprising
multiple existing data sources, each specifying a limited set of
selectable values that may be submitted via the instance of the
interface widget (Operation 208).
[0075] In an embodiment, the interface design engine obtains a list
identifying existing data sources. The list is stored at a data
repository of the interface design engine. The list identifies the
data sources by referencing an address and/or identifier of the
data sources. The interface design engine displays a list of the
addresses and/or identifiers of the data sources.
[0076] In an additional or alternative embodiment, the interface
design engine identifies existing data sources from a particular
memory location. The interface design engine obtains information
identifying the particular memory location from a data repository
of the interface design engine. The particular memory location may
be an address corresponding to, for example, a particular
electronic folder, a particular machine or server, or a particular
disk sector of a machine. The interface design engine may identify
all or a subset of existing data sources from the particular memory
location.
[0077] The interface design engine may identify all existing data
sources stored at the particular memory location. The interface
design engine may identify an identifier corresponding to each data
source. The interface design engine may display a list of
identifiers of the data sources stored at the particular memory
location.
[0078] The interface design engine may identify a subset of the
existing data sources stored at the particular memory location. The
interface design engine may search through the data sources stored
at the particular memory location to identify data sources that are
associated with a particular tag. The interface design engine may
identify an identifier corresponding to each tagged data source.
The interface design engine may display a list of identifiers of
the tagged data sources.
[0079] One or more embodiments include determining whether there is
any user input selecting an existing data source (Operation 210).
The interface design engine displays a user interface element for
accepting user input selecting at least one of the existing data
sources displayed at Operation 208. The user interface element may
be, for example, a set of checkboxes corresponding to the data
sources. The interface design engine may also display a user
interface element accepting user input indicating that no data
source is to be selected. As an example, the interface design
engine may display a "Cancel" button, a "No Existing Data Source"
button, and/or a "Default" button. The interface design engine
receives user input via one or more user interface elements.
[0080] If there is user input selecting an existing data source,
then the limited set of selectable values specified by the selected
data source is used (Operation 212). The interface design engine
stores the selected data source in association with the instance of
the interface widget.
[0081] In an embodiment, the selected data source is a particular
data field of a database and/or table. The database and/or table is
associated with multiple data fields. Each entry, stored in the
database and/or table, includes information corresponding to each
data field. Values stored under the particular data field are
identified as the limited set of selectable values to be used.
Values stored under other data fields are not identified as the
limited set of selectable values for the instance of the interface
widget.
[0082] In an embodiment, the selected data source is a database
and/or table. The database and/or table is organized according to a
schema associated with multiple data fields. Each entry, stored in
the database and/or table, includes information corresponding to
each data field. A particular data field is tagged as storing the
limited set of selectable values. The interface design engine
identifies the particular data field based on the tag. Values
stored under the particular data field are identified as the
limited set of selectable values to be used. Values stored under
other data fields are not identified as the limited set of
selectable values for the instance of the interface widget.
[0083] If there is no user input selecting an existing data source,
then a default set of selectable values is used (Operation 214). A
default set of selectable values is stored in a data repository of
the interface design engine. The interface design engine identifies
the default set of selectable values from the data repository.
[0084] One or more embodiments include displaying a list comprising
multiple destinations that may store data submitted via the
instance of the interface widget (Operation 216).
[0085] In an embodiment, the interface design engine obtains a list
identifying destinations that may be used for storing data
submitted via the instance of the interface widget. The list is
stored at a data repository of the interface design engine. The
list identifies the destinations by referencing an address and/or
identifier of the destinations. The interface design engine
displays a list of the addresses and/or identifiers of the
destinations.
[0086] In an additional or alternative embodiment, the interface
design engine identifies destinations that may be used for storing
data submitted via the instance of the interface widget from a
particular memory location. The interface design engine obtains
information identifying the particular memory location from a data
repository of the interface design engine. The particular memory
location may be an address corresponding to, for example, a
particular electronic folder, a particular machine or server, or a
particular disk sector of a machine. The interface design engine
may identify all or a subset of destinations stored at the
particular memory location.
[0087] The interface design engine may identify all destinations
stored at the particular memory location. The interface design
engine may identify an identifier corresponding to each
destination. The interface design engine may display a list of
identifiers of the destinations stored at the particular memory
location.
[0088] The interface design engine may identify a subset of the
destinations stored at the particular memory location. The
interface design engine may search through the destinations stored
at the particular memory location to identify destinations that are
associated with a particular tag. The interface design engine may
identify an identifier corresponding to each tagged destination.
The interface design engine may display a list of identifiers of
the tagged destinations.
[0089] One or more embodiments include determining whether there is
any user input selecting a destination (Operation 218). The
interface design engine displays a user interface element for
accepting user input selecting at least one of the destinations
displayed at Operation 216. The user interface element may be, for
example, a set of checkboxes corresponding to the destinations. The
interface design engine may also display a user interface element
accepting user input indicating that no destination is to be
selected. As an example, the interface design engine may display a
"Cancel" button, a "No Destination" button, and/or a "Default"
button. The interface design engine receives user input via one or
more user interface elements.
[0090] If there is user input selecting a destination, then the
selected destination is used (Operation 220). The interface design
engine uses the selected destination for storing data submitted via
the instance of the interface widget.
[0091] If there is no user input selecting a destination, then a
default destination is used (Operation 222). Information
identifying a default destination is stored in a data repository of
the interface design engine. The interface design engine identifies
the default destination from the data repository.
[0092] One or more embodiments include configuring the instance of
the first interface widget using (a) the selected or default data
source and/or (b) the selected and/or default destination
(Operation 224). The interface design engine stores the customized
widget properties associated with the instance of the interface
widget. Storing customized widget properties comprises configuring
a data source and/or a destination for the instance of the
interface widget.
[0093] The interface design engine configures the instance of the
interface widget for accepting a value from a limited set of
selectable values specified by the selected data source. Hence, the
instance of the interface widget is integrated with the existing
data source selected at Operation 210. Alternatively, the interface
design engine configures the instance of the interface widget for
accepting a value from the default set of selectable values. The
instance of the interface widget may only accept a value from the
set of selectable values. The instance of the interface widget does
not accept values other than the set of selectable values.
[0094] The interface design engine configures the instance of the
interface widget to store data submitted via the instance of the
interface widget at the selected destination or the default
destination. The interface design engine maps data submission,
received via the instance of the interface widget, to storage at
the selected destination or the default destination.
4. CONFIGURING A FORM PROPERTY FOR A PARTICULAR FORM
[0095] FIG. 3 illustrates an example set of operations for
configuring a form property for a particular form, in accordance
with one or more embodiments. One or more operations illustrated in
FIG. 3 may be modified, rearranged, or omitted all together.
Accordingly, the particular sequence of operations illustrated in
FIG. 3 should not be construed as limiting the scope of one or more
embodiments.
[0096] One or more embodiments include displaying a form-properties
section for designing a particular form (Operation 302). An
interface design engine displays a design user interface. The
design user interface includes the form-properties section. The
form-properties section includes customizable form properties of
the particular form.
[0097] One or more embodiments include displaying a list comprising
users and/or roles for configuration of approval settings
(Operation 304).
[0098] In an embodiment, the interface design engine obtains a list
identifying users and/or roles that are available for selection.
The list is stored at a data repository of the interface design
engine. The interface design engine identifies a name and/or
identifier corresponding to each user and/or role in the list. The
interface design engine displays a list of names and/or identifiers
of the users and/or roles. The users and/or roles may be selected
for configuring approval settings for the particular form.
[0099] In an additional or alternative embodiment, the interface
design engine identifies the users and/or roles based on an
existing data source. As an example, information identifying the
users and/or roles may be stored in an existing database. The
interface design engine retrieves and/or imports the names and/or
identifiers of the users and/or roles from the data source. The
interface design engine displays a list of names and/or identifiers
of the users and/or roles. The users and/or roles may be selected
for configuring approval settings for the particular form.
[0100] In an additional or alternative embodiment, the interface
design engine identifies roles from the perspective of an end user
submitting a request via the particular form. A role may be, for
example, a supervisor of the end user. Another role may be, for
example, a department head of a department of the end user. The
interface design displays a list of the roles from the perspective
of the end user. The roles may be selected for configuring approval
settings of the particular form.
[0101] One or more embodiments include receiving user input
selecting a sequence of users and/or roles required for approving a
request submitted via the particular form (Operation 306). The
interface design engine displays a user interface element for
accepting user input selecting at least one of the users and/or
roles displayed at Operation 304. The user interface element may
be, for example, a set of checkboxes corresponding to the users
and/or roles. The interface design engine receives user input via
the user interface element. The selected users and/or roles are
required for approving a request submitted via the particular
form.
[0102] The interface design engine may receive user input selecting
a particular sequence of users and/or roles. As an example, a first
user input may comprise selecting user John Smith. A second user
input may comprise selecting user Mary Jones. Based on the user
input, an approval process for the particular form includes first
obtaining approval from John Smith and then obtaining approval from
Mary Jones.
[0103] One or more embodiments include displaying a list comprising
users and/or roles for configuration of security settings
(Operation 308).
[0104] In an embodiment, the interface design engine obtains a list
identifying users and/or roles that are available for selection.
The list is stored at a data repository of the interface design
engine. The interface design engine identifies a name and/or
identifier corresponding to each user and/or role in the list. The
interface design engine displays a list of names and/or identifiers
of the users and/or roles. The users and/or roles may be selected
for configuring security settings of the particular form.
[0105] In an additional or alternative embodiment, the interface
design engine identifies the users and/or roles based on an
existing data source. As an example, information identifying the
users and/or roles may be stored in an existing database. The
interface design engine retrieves and/or imports the names and/or
identifiers of the users and/or roles from the data source. The
interface design engine displays a list of names and/or identifiers
of the users and/or roles from the data source. The users and/or
roles may be selected for configuring security settings of the
particular form.
[0106] In an additional or alternative embodiment, the interface
design engine identifies roles from the perspective of an end user
submitting a request via the particular form. A role may be, for
example, a supervisor of the end user. Another role may be, for
example, a department head of a department of the end user. The
interface design displays a list of the roles from the perspective
of the end user. The roles may be selected for configuring security
settings of the particular form.
[0107] The list of users and/or roles available for configuring
security settings may be the same as or different from the list of
users and/or roles, identified at Operation 304, available for
configuring approval settings.
[0108] One or more embodiments include receiving user input
selecting users and/or roles having permissions to submit a request
via the particular form (Operation 310). The interface design
engine displays a user interface element for accepting user input
selecting at least one of the users and/or roles displayed at
Operation 308. The user interface element may be, for example, a
set of checkboxes corresponding to the users and/or roles. The
interface design engine receives user input via the user interface
element. The selected users and/or roles are associated with
permissions for submitting a request via the particular form.
[0109] One or more embodiments include displaying a list comprising
landing pages for configuration of landing page settings (Operation
312). The interface design engine identifies landing pages
associated with one or more applications. Each landing page is to
be displayed by the corresponding application to an end user of the
application. The interface design engine identifies the names
and/or identifiers of the landing pages. The interface design
engine displays a list of names and/or identifies of the landing
pages.
[0110] One or more embodiments include receiving user input
selecting landing pages for displaying an icon representing the
particular form (Operation 314). The interface design engine
displays a user interface element for accepting user input
selecting at least one of the landing pages displayed at Operation
312. The user interface element may be, for example, a set of
checkboxes corresponding to the landing pages. The interface design
engine receives user input via the user interface element. The
selected landing pages are associated with the particular form.
[0111] One or more embodiments include configuring the particular
form using (a) the selected users and/or roles for the approval
settings, (b) the selected users and/or roles for the security
settings, and (c) the selected landing pages (Operation 316). The
interface design engine stores the customized form properties
associated with the particular form. Storing the customized form
properties comprises configuring approval settings, security
settings, and/or landing pages for the particular form.
[0112] The interface design engine configures the particular form
with a set of approval settings. The approval settings require that
a request submitted via the particular form be approved by the
sequence of users and/or roles selected at Operation 306.
[0113] The interface design engine configures the particular form
with a set of security settings. The security settings provide
permissions for submitting a request via the particular form to the
users and/or roles selected at Operation 310. Users and/or roles
that were not selected do not have permissions for submitting a
request via the particular form.
[0114] The interface design engine associates the particular form
with the selected landing pages. The interface design engine may
add a tag to the selected landing pages. Based on the tag, a
selected landing pages displays an icon representing the particular
form.
5. RECEIVING A REQUEST VIA A PARTICULAR FORM
[0115] FIG. 4 illustrates an example set of operations for
receiving a request via a particular form, in accordance with one
or more embodiments. One or more operations illustrated in FIG. 4
may be modified, rearranged, or omitted all together. Accordingly,
the particular sequence of operations illustrated in FIG. 4 should
not be construed as limiting the scope of one or more
embodiments.
[0116] One or more embodiments include displaying a particular
landing page, including an icon representing a particular form
(Operation 402). Execution of a particular application is initiated
by a particular end user. The particular application identifies one
or more landing pages associated with the particular end user. The
particular application determines that the particular landing page
is associated with the particular form. Based on the association
with the particular form, the particular application displays the
particular landing page including the icon representing the
particular form.
[0117] One or more embodiments include receiving user input
requesting display of the particular form from the particular end
user (Operation 404). The particular application receives user
input selecting the icon representing the particular form from the
particular landing page. The user input comprises a request to
display the particular form.
[0118] One or more embodiments include determining whether the
particular user has permissions associated with the particular form
(Operation 406). The particular application obtains security
settings associated with the particular form. The security settings
are stored as part of the form properties of the particular form.
The particular application determines whether the particular end
user has permissions for submitting a request via the particular
form based on the security settings.
[0119] The particular application identifies end users that have
permissions to access the particular form based on the security
settings. The particular application determines whether the
particular end user is one of the end users that have permissions
to access the particular form.
[0120] The particular application identifies roles that have
permissions to access the particular form based on the security
settings. The particular application determines whether the
particular end user is associated with one of the roles that have
permissions to access the particular form.
[0121] If the particular end user does not have permissions
associated with the particular form, then an error message is
displayed (Operation 410). The particular application does not
display the particular form to the particular end user. The
particular end user does not have access to the particular
form.
[0122] If the particular end user has permissions associated with
the particular form, then the particular form is displayed
(Operation 408). The particular application identifies instances of
interface widgets that have been selected for inclusion into the
particular form. The particular application displays the particular
form, including at least one instance of an interface widget.
[0123] One or more embodiments include determining whether the
instance of the interface widget is associated with an existing
data source (Operation 412). The particular application obtains
widget properties of the instance of the interface widget. One
widget property is a set of selectable values for the instance of
the interface widget. The particular application determines whether
an existing data source has been selected for specifying the set of
selectable values.
[0124] If the instance of the interface widget is associated with
an existing data source, then the particular form displays the
limited set of selectable values specified by the existing data
source (Operation 414). The particular application identifies the
data source associated with the instance of the interface widget
based on the widget properties of the instance of interface widget.
The particular application retrieves and/or imports the limited set
of selectable values from the data source. The particular
application displays the limited set of selectable values in the
particular form. The limited set of selectable values are provided
to the particular end user for selection. At least one of the
limited set of selectable values may be selected for submission via
the instance of the interface widget.
[0125] In an embodiment, the particular application retrieves the
limited set of selectable values that are currently stored by the
data source. The limited set of selectable values currently stored
by the data source may be the same as or different from the limited
set of selectable values that were stored by the data source at the
time the instance of the interface widget was configured to become
associated with the data source. As an example, during the design
of a particular form, an instance of an interface widget may be
configured as being associated with a particular data source. The
particular data source may include the values: United States,
Canada. Subsequently, the particular form may be displayed to an
end user. At this time, the particular data source may include the
values: United States, Mexico. The particular form may display a
limited set of selectable values for the instance of the interface
widget. The limited set of selectable values are the values
currently stored by the data store: United States, Mexico.
[0126] In an embodiment, the particular application retrieves the
limited set of selectable values from a particular data field of
the data source. The data source is organized according to a schema
associated with multiple data fields. Each entry, stored in the
data source, includes information corresponding to each data field.
A particular data field is tagged as storing the limited set of
selectable values. The particular application displays values
stored under the particular data field as the limited set of
selectable values for the instance of the interface widget.
[0127] If the instance of the interface widget is not associated
with an existing data source, then the particular form displays a
default set of selectable values (Operation 416). The particular
application obtains the default set of selectable values from a
data repository. The particular application displays the default
set of selectable values in the particular form. The default set of
selectable values are provided to the particular end user for
selection. At least one of the default set of selectable values may
be selected for submission via the instance of the interface
widget.
[0128] One or more embodiments include receiving user input
selecting a value from the limited set of selectable values
specified by the existing data source via the instance of the
interface widget (Operation 418). The particular application
displays a user interface element for accepting user input
selecting a value from the set of selectable values. The user
interface element may be, for example, a dropdown menu. The
particular application receives user input via the user interface
element.
[0129] One or more embodiments include receiving user input
submitting a request via the particular form (Operation 420). The
particular application receives user input to one or more fields of
the particular form. The particular application displays a user
interface element for accepting user input submitting a request via
the particular form. The user interface element may be, for
example, a "Submit" button. The particular application receives
user input via the user interface element. Based on the user input,
information received via the fields of the particular form,
including the instance of the interface widget, are submitted.
[0130] One or more embodiments include storing the value received
via the instance of the interface widget at a destination
associated with the instance of the interface widget (Operation
422). The particular application identifies the destination based
on the widget properties associated with the instance of the
interface widget. The particular application causes the value
received via the instance of the interface widget to be stored at
the destination. The particular application may transmit the
received value to the destination. Alternatively, the particular
application may directly store the received value at the
destination.
[0131] One or more embodiments include transmitting the request
submitted via the particular form to each user and/or role
specified in the approval settings associated with the particular
form (Operation 424). The particular application identifies a
sequence of users and/or roles that are required for approving the
request submitted via the particular form from the approval
settings of the particular form. The approval settings are stored
as part of the form properties associated with the particular
form.
[0132] In an embodiment, the sequence of users and/or roles may
include User X. In an embodiment, execution of the particular
application is initiated by User X. Upon execution of the
particular application, the particular application may display the
request, submitted by the particular end user, to User X. In an
alternative embodiment, the particular application transmits the
request to User X via electronic mail or other means.
[0133] In an embodiment, the sequence of users and/or roles may
include a particular role. The particular role may be a title
within the company, such as "Chief Executive Officer."
Alternatively, the particular role may be specified from the
perspective of the particular end user. The particular role may be,
for example, a supervisor of the end user. The particular
application may determine that User Y is associated with the
particular role. The particular application transmits the request,
submitted by the particular end user, to User Y.
[0134] The particular application transmits the request to the
first user and/or role in the sequence of users and/or roles that
are required for approving the request submitted via the particular
form. The particular application receives user input approving the
request from the first user and/or role. The particular application
transmits the request to the next user and/or role in the sequence
of users and/or roles that are required for approving the request.
The particular application receives user input approving the
request from the next user and/or role. The particular application
thus transmits the request to each of the users and/or roles that
are required for approving the request.
6. EXAMPLE EMBODIMENTS
[0135] Detailed examples are described below for purposes of
clarity. Components and/or operations described below should be
understood as specific examples which may not be applicable to
certain embodiments. Accordingly, components and/or operations
described below should not be construed as limiting the scope of
any of the claims.
[0136] FIGS. 5A-5I illustrate example screenshots of a design user
interface for designing a particular form, in accordance with one
or more embodiments. The particular form is to be used for
submitting tuition reimbursement requests to a company.
[0137] As illustrated, the design user interface includes tabs
530-538. Tab 530 corresponds to a "Form" tab. Tab 532 corresponds
to a "Layout" tab. Tab 534 corresponds to an "Instructions" tab.
Tab 536 corresponds to an "Approval" tab. Tab 538 corresponds to a
"Security" tab.
[0138] Screenshot 500 shows the design user interface under the
"Form" tab. Under the "Form" tab, the design user interface
includes elements 539. Elements 539 are customizable form
properties associated with the tuition reimbursement form. The
customizable form properties include a label and/or name of the
form, a description of the form, a status of the form, effective
dates of the form, and an owner of the form.
[0139] Screenshot 502 shows the design user interface under the
"Layout" tab. Under the "Layout" tab, the design user interface
includes sections 540-544. Section 540 corresponds to a
widget-selection section. Section 542 corresponds to a form-design
section. Section 544 corresponds to a widget-properties
section.
[0140] Section 540 includes available interface widgets 546.
Section 540 provides interface widgets 546 that are available for
selection. Interface widgets 546 may be selected for inclusion into
the tuition reimbursement form. A user may select an interface
widget 546 by dragging the interface widget 546 from section 540 to
section 542.
[0141] Interface widgets 546 include a text field, a prompt field,
a yes/no field, a code field, a date selection field, a number
field, a signed number field, and a divider. A code field is
associated with a set of selectable values. The set of selectable
values are specified by a user designing the tuition reimbursement
form. A prompt field is associated with a set of selectable values.
The set of selectable values are specified by an existing data
source. The existing data source is selected by a user designing
the tuition reimbursement form.
[0142] Section 542 includes form template 547. Form template 547
has particular dimensions suited for being displayed on a computer
monitor. Form template 547 includes instances of interface widgets
546 that have been selected. Form template 547 displays an instance
of an interface widget 546 at a particular location at which the
interface widget 546 was dropped by a user.
[0143] Section 544 includes customizable widget properties 548.
Customizable widget properties 548 correspond to one or more
instances of widget interfaces shown in form template 547. After a
particular interface widget 546 is dropped in section 542, the
customizable widget properties 548 associated with the particular
interface widget 546 are shown in section 544.
[0144] Screenshot 504 shows customizable widget properties 550 for
an instance of a prompt field. Customizable widget properties 550
include a label and/or name of the instance, a status of the
instance, and a description of the instance. Customizable widget
properties 550 further include a prompt record for the instance of
the prompt field. The prompt record is an existing data source to
be associated with the instance of the prompt field. The set of
selectable values, for the instance of the prompt field, is
specified by the associated data source. A user designing the
tuition reimbursement form may click on the user interface element
representing the prompt record to select a data source to be
associated with the instance of the prompt field. In response to
receiving user input clicking on the user interface element,
screenshot 506 is shown.
[0145] Screenshot 506 shows a list of data sources 552 that may be
associated with the instance of the prompt field. The design
interface engine obtains the list of data sources 552 from a data
repository. Each data source 522 is associated with a name and a
description.
[0146] Screenshot 508 shows an example of a data source 522 for
departments of a company. The design interface engine retrieves
information stored by the data source 522. Data source 522 is
organized according to a schema associated with data fields 553.
Data fields 553 include Department Number, Description, and Manager
Name. Data source 522 includes entries 554. One entry 554 includes
"10000" under Department Number, "Human Resources" under
Description, and "Ball, Nancy" under Manager Name. Another entry
554 includes "10500" under Department Number, "Benefits" under
Description, and "Ford, Jane" under Manager Name.
[0147] The Department Number data field stores the set of
selectable values for the instance of the prompt field. Hence, the
set of selectable values includes "10000" and "10500." Selection of
a value from the set of selectable values represents selection of
an entry 554 from data source 522.
[0148] Screenshot 510 shows the design user interface under the
"Layout" tab. Screenshot 510 includes user interface elements
representing various layouts 556. Layouts 556 includes a layout for
a computer monitor, a layout for a smartphone, and a layout for a
tablet. A user designing the tuition reimbursement form may select
a user interface element representing a particular layout 556. Form
template 547 is modified based on the selection.
[0149] The dimensions of form template 547 are modified based on
the selected layout 556. Referring to FIGS. 5B and 5F, screenshot
502 shows form template 547 having dimensions suited for being
displayed by a computer monitor. Screenshot 510 shows form template
547 having dimensions suited for being displayed by a
smartphone.
[0150] The interface widgets in form template 547 are rearranged
based on the selected layout 556. The interface widgets in
screenshot 502 are placed in two columns on the target user
interface displaying the tuition reimbursement form. As an example,
a text field labeled "School" is on the left column, while a text
field labeled "Course" is on the right column. In contrast, the
interface widgets in screenshot 510 are placed in a single column
on the target user interface displaying the tuition reimbursement
form. As an example, the text field labeled "School" is above the
text field labeled "Course." The same text fields appear in both
screenshots 502 and 510, but the text fields appear in different
positions relative to each other.
[0151] Screenshot 514 shows the design user interface under the
"Approval" tab. Screenshot 514 includes elements 557. Elements 557
are configured to accept user input selecting a sequence of users
and/or roles required for approving a request submitted via the
tuition reimbursement form. A user designing the tuition
reimbursement form may click on elements 557. In response to the
user input, the design user interface identifies users and/or roles
available for selection from a data repository. As an example, the
design user interface may import the users and/or roles from an
application configured to manage employee profiles of the company.
The design user interface displays a list of the users and/or
roles. The design user interface accepts user input selecting one
of the users and/or roles. The design user interface may accept
further user input selecting additional users and/or roles. The
design user interface may accept user input ordering the selected
users and/or roles in a particular sequence.
[0152] Screenshot 516 shows the design user interface under the
"Security" tab. Screenshot 516 includes elements 558. Elements 558
are configured to accept user input selecting users and/or roles
having permissions to submit a request via the tuition
reimbursement form. A user designing the tuition reimbursement form
may click on elements 558. In response to the user input, the
design user interface identifies users and/or roles available for
selection from a data repository. As an example, the design user
interface may import the users and/or roles from an application
configured to manage employee profiles of the company. The design
user interface displays a list of the users and/or roles. The
design user interface accepts user input selecting one of the users
and/or roles. The design user interface may accept further user
input selecting additional users and/or roles.
[0153] As illustrated in this example, a first user and/or role
required in the approval process is a supervisor of a particular
end user submitting a request via the tuition reimbursement form. A
second user and/or role required in the approval process is a vice
president.
[0154] Screenshot 516 includes button 560. Button 560 is labeled
"Activate." A user designing the tuition reimbursement form may
click on button 560. In response to the user input, the design
interface engine stores the tuition reimbursement form. The design
interface engine configures the instance of the prompt widget such
that the set of selectable values are specified by the selected
data source. The design interface engine configures the tuition
reimbursement form such that a request submitted via the tuition
reimbursement form is approved by the selected sequence of users
and/or roles. The design interface engine configures the tuition
reimbursement form such that the selected users and/or roles have
permissions to submit a request via the tuition reimbursement
form.
[0155] Screenshot 518 shows a list of forms that have been designed
using the design interface engine. The list of forms includes the
tuition reimbursement form. Screenshot 518 includes button 562.
Button 562 is labeled "Add to Homepage." A user may click on button
562. In response to the user input, the design interface engine
identifies landing pages 564 from a data repository. As an example,
the design user interface may import information identifying
landing pages 564 from a particular application. Landing pages 564
includes, for example, an Employee Self Service page, and a
Learning Center page. The design user interface accepts user input
selecting one or more of landing pages 564. The selected landing
pages 564 are configured to display an icon representing the
tuition reimbursement form.
[0156] FIGS. 6A-6C illustrate example screenshots for submitting a
request via a particular form, in accordance with one or more
embodiments.
[0157] An end user initiates execution of a particular application.
The particular application identifies landing pages 612 that are
accessible by the end user. A landing page 612 may be tagged to
indicate that the landing page 612 is associated with a particular
form.
[0158] One landing page 612 accessible to the end user is the
"Employee Self Service" landing page 612. A tag associated with the
"Employee Self Service" landing page 612 indicates that the
"Employee Self Service" landing page is associated with the tuition
reimbursement form.
[0159] Screenshot 600 shows the "Employee Self Service" landing
page 612. The "Employee Self Service" landing page includes an icon
613 representing the tuition reimbursement form. The particular
application accepts user input selecting icon 613. In response to
the user input, the particular application displays the tuition
reimbursement form.
[0160] Screenshot 602 shows the tuition reimbursement form. The
tuition reimbursement form includes elements 614. Elements 614
includes, for example, a text field labeled "School" and a text
field labeled "Course." Elements 614 further includes a prompt
field labeled "Department." The end user may select the prompt
field. The particular application identifies a data source
associated with the prompt field. The particular application
obtains a set of selectable values from the associated data source.
The particular application displays the set of selectable values.
The particular application accepts user input selecting a value
from the set of selectable values. The particular application
stores information submitted via elements 614.
[0161] Screenshot 604 shows an approval process 616 for the tuition
reimbursement form. Based on the form properties of the tuition
reimbursement form, the approval process 616 includes the following
sequence of users and/or roles: (1) a supervisor of the end user,
and (2) one or more vice presidents. The particular application
identifies the supervisor of the end user from a data repository.
The particular application transmits the request of the end user to
the supervisor. The particular application receives user input
indicating an approval of the request from the supervisor. The
particular application identifies the vice presidents from a data
repository. The particular application transmits the request to at
least one of the vice presidents. The particular application
receives user input indicating an approval of the request from the
vice president.
[0162] FIG. 7 illustrates an example of a destination that is
shared by two forms, in accordance with one or more
embodiments.
[0163] Table 700 is a destination that is shared by forms 702-704.
Table 700 is configured to store requests submitted by either form
702 or form 704. Form 702 is a tuition reimbursement form. Form 704
is a project postponement form. Forms 702-704 are associated with a
particular application.
[0164] Table 700 includes columns 710-714. Column 710 stores an
identifier of a particular form that is being used to submit a
request, such as form 702 or form 704. Column 712 stores data
submitted via widget 718 of form 702 and data submitted via widget
724 of form 704. Column 714 stores data submitted via widget 720 of
form 702 and data submitted via widget 728 of form 704.
[0165] Table 700 includes two entries. The first entry is a request
submitted via form 702. The second entry is a request submitted via
form 704.
[0166] A particular end user uses form 702 to submit a tuition
reimbursement request. The particular end user enters "Jul. 5,
2016" into widget 718. The particular end user selects the value
"43000" from a set of selectable values for widget 720.
[0167] The particular application determines that the destination
for widget 718 is column 712. The particular application determines
that the destination for widget 720 is column 714. The particular
application stores "Jul. 5, 2016" under column 712 and "43000"
under column 714.
[0168] An additional end user uses form 704 to submit a project
postponement request. The additional end user enters "Aug. 31,
2016" into widget 724. The additional end user selects the value
"Implementation" from a set of selectable values for widget
728.
[0169] The particular application determines that the destination
for widget 724 is column 712. The particular application determines
that the destination for widget 728 is column 714. The particular
application stores "Aug. 31, 2016" under column 712 and
"Implementation" under column 714.
7. MISCELLANEOUS; EXTENSIONS
[0170] Embodiments are directed to a system with one or more
devices that include a hardware processor and that are configured
to perform any of the operations described herein and/or recited in
any of the claims below.
[0171] In an embodiment, a non-transitory computer readable storage
medium comprises instructions which, when executed by one or more
hardware processors, causes performance of any of the operations
described herein and/or recited in any of the claims.
[0172] Any combination of the features and functionalities
described herein may be used in accordance with one or more
embodiments. In the foregoing specification, embodiments have been
described with reference to numerous specific details that may vary
from implementation to implementation. The specification and
drawings are, accordingly, to be regarded in an illustrative rather
than a restrictive sense. The sole and exclusive indicator of the
scope of the invention, and what is intended by the applicants to
be the scope of the invention, is the literal and equivalent scope
of the set of claims that issue from this application, in the
specific form in which such claims issue, including any subsequent
correction.
8. HARDWARE OVERVIEW
[0173] According to one embodiment, the techniques described herein
are implemented by one or more special-purpose computing devices.
The special-purpose computing devices may be hard-wired to perform
the techniques, or may include digital electronic devices such as
one or more application-specific integrated circuits (ASICs) or
field programmable gate arrays (FPGAs) that are persistently
programmed to perform the techniques, or may include one or more
general purpose hardware processors programmed to perform the
techniques pursuant to program instructions in firmware, memory,
other storage, or a combination. Such special-purpose computing
devices may also combine custom hard-wired logic, ASICs, or FPGAs
with custom programming to accomplish the techniques. The
special-purpose computing devices may be desktop computer systems,
portable computer systems, handheld devices, networking devices or
any other device that incorporates hard-wired and/or program logic
to implement the techniques.
[0174] For example, FIG. 8 is a block diagram that illustrates a
computer system 800 upon which an embodiment of the invention may
be implemented. Computer system 800 includes a bus 802 or other
communication mechanism for communicating information, and a
hardware processor 804 coupled with bus 802 for processing
information. Hardware processor 804 may be, for example, a general
purpose microprocessor.
[0175] Computer system 800 also includes a main memory 806, such as
a random access memory (RAM) or other dynamic storage device,
coupled to bus 802 for storing information and instructions to be
executed by processor 804. Main memory 806 also may be used for
storing temporary variables or other intermediate information
during execution of instructions to be executed by processor 804.
Such instructions, when stored in non-transitory storage media
accessible to processor 804, render computer system 800 into a
special-purpose machine that is customized to perform the
operations specified in the instructions.
[0176] Computer system 800 further includes a read only memory
(ROM) 808 or other static storage device coupled to bus 802 for
storing static information and instructions for processor 804. A
storage device 810, such as a magnetic disk or optical disk, is
provided and coupled to bus 802 for storing information and
instructions.
[0177] Computer system 800 may be coupled via bus 802 to a display
812, such as a cathode ray tube (CRT), for displaying information
to a computer user. An input device 814, including alphanumeric and
other keys, is coupled to bus 802 for communicating information and
command selections to processor 804. Another type of user input
device is cursor control 816, such as a mouse, a trackball, or
cursor direction keys for communicating direction information and
command selections to processor 804 and for controlling cursor
movement on display 812. This input device typically has two
degrees of freedom in two axes, a first axis (e.g., x) and a second
axis (e.g., y), that allows the device to specify positions in a
plane.
[0178] Computer system 800 may implement the techniques described
herein using customized hard-wired logic, one or more ASICs or
FPGAs, firmware and/or program logic which in combination with the
computer system causes or programs computer system 800 to be a
special-purpose machine. According to one embodiment, the
techniques herein are performed by computer system 800 in response
to processor 804 executing one or more sequences of one or more
instructions contained in main memory 806. Such instructions may be
read into main memory 806 from another storage medium, such as
storage device 810. Execution of the sequences of instructions
contained in main memory 806 causes processor 804 to perform the
process steps described herein. In alternative embodiments,
hard-wired circuitry may be used in place of or in combination with
software instructions.
[0179] The term "storage media" as used herein refers to any
non-transitory media that store data and/or instructions that cause
a machine to operate in a specific fashion. Such storage media may
comprise non-volatile media and/or volatile media. Non-volatile
media includes, for example, optical or magnetic disks, such as
storage device 810. Volatile media includes dynamic memory, such as
main memory 806. Common forms of storage media include, for
example, a floppy disk, a flexible disk, hard disk, solid state
drive, magnetic tape, or any other magnetic data storage medium, a
CD-ROM, any other optical data storage medium, any physical medium
with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM,
NVRAM, any other memory chip or cartridge.
[0180] Storage media is distinct from but may be used in
conjunction with transmission media. Transmission media
participates in transferring information between storage media. For
example, transmission media includes coaxial cables, copper wire
and fiber optics, including the wires that comprise bus 802.
Transmission media can also take the form of acoustic or light
waves, such as those generated during radio-wave and infra-red data
communications.
[0181] Various forms of media may be involved in carrying one or
more sequences of one or more instructions to processor 804 for
execution. For example, the instructions may initially be carried
on a magnetic disk or solid state drive of a remote computer. The
remote computer can load the instructions into its dynamic memory
and send the instructions over a telephone line using a modem. A
modem local to computer system 800 can receive the data on the
telephone line and use an infra-red transmitter to convert the data
to an infra-red signal. An infra-red detector can receive the data
carried in the infra-red signal and appropriate circuitry can place
the data on bus 802. Bus 802 carries the data to main memory 806,
from which processor 804 retrieves and executes the instructions.
The instructions received by main memory 806 may optionally be
stored on storage device 810 either before or after execution by
processor 804.
[0182] Computer system 800 also includes a communication interface
818 coupled to bus 802. Communication interface 818 provides a
two-way data communication coupling to a network link 820 that is
connected to a local network 822. For example, communication
interface 818 may be an integrated services digital network (ISDN)
card, cable modem, satellite modem, or a modem to provide a data
communication connection to a corresponding type of telephone line.
As another example, communication interface 818 may be a local area
network (LAN) card to provide a data communication connection to a
compatible LAN. Wireless links may also be implemented. In any such
implementation, communication interface 818 sends and receives
electrical, electromagnetic or optical signals that carry digital
data streams representing various types of information.
[0183] Network link 820 typically provides data communication
through one or more networks to other data devices. For example,
network link 820 may provide a connection through local network 822
to a host computer 824 or to data equipment operated by an Internet
Service Provider (ISP) 826. ISP 826 in turn provides data
communication services through the world wide packet data
communication network now commonly referred to as the "Internet"
828. Local network 822 and Internet 828 both use electrical,
electromagnetic or optical signals that carry digital data streams.
The signals through the various networks and the signals on network
link 820 and through communication interface 818, which carry the
digital data to and from computer system 800, are example forms of
transmission media.
[0184] Computer system 800 can send messages and receive data,
including program code, through the network(s), network link 820
and communication interface 818. In the Internet example, a server
830 might transmit a requested code for an application program
through Internet 828, ISP 826, local network 822 and communication
interface 818.
[0185] The received code may be executed by processor 804 as it is
received, and/or stored in storage device 810, or other
non-volatile storage for later execution.
[0186] In the foregoing specification, embodiments of the invention
have been described with reference to numerous specific details
that may vary from implementation to implementation. The
specification and drawings are, accordingly, to be regarded in an
illustrative rather than a restrictive sense. The sole and
exclusive indicator of the scope of the invention, and what is
intended by the applicants to be the scope of the invention, is the
literal and equivalent scope of the set of claims that issue from
this application, in the specific form in which such claims issue,
including any subsequent correction.
* * * * *