Patent Application
20170083186
This relates to a graphical user interface (GUI) for generating an invitation and for electronically displaying the invitation.
Websites of stationery vendors may enable a customer to select and customize a layout for an invitation card. The vendor prints the invitation cards that incorporate the selected-and-customized design, and ships the cards to the customer. The customer then mails the cards to people the customer wants to invite.
A graphical user interface (GUI) displays a scene on a display screen of a communication device. The scene includes an image of a background, an image of an invitation in front of the background, an image of a three-dimensional ancillary item in front of the background, and an image of a reply form in front of the background. The displaying includes panning across the scene such that the background, the ancillary item and the invitation appear to move along the screen. While the reply form is in the scene, input is received from a recipient of the invitation for the recipient to interact with the reply form to reply to the invitation.
The example system 100 includes a non-transitory hardware server 101 that has a processor 102 (which can represent multiple processors). The processor 102 executes program instructions of software code. The code is stored on a non-transitory hardware computer-readable data storage medium 103, such as a computer hard drive device, to implement the functions of the server 101. The server 101 in this example hosts a website that provides the first GUI. The website is associated with a greeting card vendor (merchant, manufacturer). The storage medium 103 includes a database 104 that stores images and text provided by the first user. The database 104 also stores design templates for invitation cards and reply forms.
The first and second GUIs in this example are provided, respectively, on a first communication device 110a of the first user and a second communication device 110b of the second user. Examples communication devices 110a, 110b are a personal computer (PC) and a mobile communication device such as a smart phone. Each communication device 110a, 110b has a processor 111a, 111b for executing software commands and a non-transitory hardware processor-readable data storage medium 112a, 112b for storing the commands. Each communication device 110a, 110b also has a user interface that includes a display screen 113a, 113b and a user input device 114a, 114b for implementing the respective GUI. The input device 114a, 114b may include a mouse, a keypad and a touch-screen for inputting user entries. Each communication device 110a, 110b may communicate with the server 101 through a communication network such as the Internet 120.
Some or all of the software code for implementing each GUI may be stored at and executed by the server 101. The remainder of the software code for implementing the respective GUI may be stored in and executed by the respective communication device 110a, 110b. Alternatively, all of the software code for implementing the respective GUI may be stored in and executed by the respective user device 110a, 110b, such that a server is unnecessary. For example, the first communication device 110a might send the invitation through the Internet 120 without use of the server 120.
The invitation is to an event. Example events are a party (e.g., for a birthday, wedding, graduation), a meeting (e.g., business meeting for a business, committee meeting for an organization), a rally (e.g., political), a dinner (e.g., with a friend at the first user's home or at a restaurant), and a concert.
The first user in this example is both a sender and an inviter, in that the first user arranges for the system 100 to send the invitation to invite the second user to the event.
The second user in this example is both a recipient and an invitee, in that the second user is a recipient of the invitation. The number of invitees receiving the invitation may be any number. There might be only one invitee in a scenario in which the inviter is inviting one friend to dinner. There might be thousands of invitees in a scenario in which the inviter is inviting people to a rally.
The invitation in this example is in the form of a realistic virtual card. “Virtual” in that it is seen by both the inviter and the invitee in a respective (i.e., first and second) GUI on the respective communication device's display screen. And “realistic” (photorealistic) in that it appears (to the invitee and/or the inviter) as a photograph of a real card made of paper stock. The realism might be reinforced by the respective GUI portraying the card's surface texture, grain, shadow, viewing-angle effects, and tilt. Examples of different textures are glossy, matte, smooth and grainy (e.g., grain of the paper stock). An example of portraying shadow is portray shadow made by the card against a background surface (such as shadow 410 in
The inviter might upload, into the Image Upload Window 300, a file containing moving content, such as a video or animated image. For example, if the event is a birthday for a child, the video file or animated file might show the child moving. The first GUI might extract, from the video/animated file, a still image of the child to use in the composited scene. Or the first GUI might use the video/animated file as is, such that the child will appear to be moving in the final composited scene.
Before or after selecting the invitation, the inviter may use the Invitation Selection Window 310 in the first GUI to customize the invitation (step 203). This customizing might be done by the user sweeping a mouse across (swiping) a passage (section) of text to highlight the passage, and typing (e.g., by using a keypad) text that will replace the passage. The GUI may also enable the inviter to revise the font and size in which each text passage is rendered. This might be done by right-clicking on a text passage to open a formatting window from which to select a font and size for the passage. The first GUI may also enable the inviter to move each text passage to a different location on the invitation 311a. This might be done by clicking and dragging the respective text passage. The first GUI may also enable the user to insert one or more of the user-uploaded images 301 into the invitation 311a. This might be done by clicking-and-dragging the uploaded image 301 to a desired location on the invitation 311a. The first GUI may enable the inviter to select the color scheme and color tone of the invitation 311a as well as the shape of the invitation card itself (die cut shape).
Each scene further includes at least one image of a three-dimensional ancillary item in front of the background (i.e., between the background and the viewer). The ancillary item is ancillary in that it is other than the invitation. The ancillary item may be related or unrelated to the invitation and related or unrelated to the event. Scene 331a has many such ancillary items, which include plates of food, a box of berries and a napkin, with each ancillary item spaced away from (separated from) each other ancillary item in the view. The ancillary items in scene 331b include a potted plant, a bowl of food and an empty bowl. In scene 331c, the ancillary items is a tractor. In scene 331d, the ancillary item includes people. In another example, the background might be a marquee of a theater, and the invitation might be in the form of lettering on the marquee. The inviter may select one of the scenes 331a-331d by clicking on it (e.g., with a mouse) or touching it (e.g., with a touch screen).
The inviter may use the Scene Selection Window 330 in the first GUI to customize the scene (step 205). This customizing may include inserting one or more of the user-uploaded images into the scene. An example of an uploaded image to be inserted into the scene, if the event is a birthday, is an image of a child whose birthday it is—or what would appear (in the scene) to be an image of a photograph of the child. The first GUI may also enable the user to insert a video (movie clip, animation) into the scene. An example of an uploaded clip to be inserted into the scene is a video of a child whose birthday it is. So that child would appear to be both present in the scene and moving in the scene displayed by the second GUI to the invitee. The image of an ancillary item might be an image of a display device, such as a television, that is appearing to be displaying a movie clip (video) that is provided by the inviter. For example, if the event is a birthday, the television in the scene may be showing a movie clip of the child whose birthday it is.
In this example, the candidate background scenes (for the user to choose from) are provided by the vendor. Alternatively, the background may be provided by the inviter. For example, the inviter may upload an image to be used as the scene. The image might be drawn or otherwise-rendered by the inviter to appear as a 3-dimensional environment. Or the inviter may upload a video clip or animated GIF file. The animated GIF file might include a 3-dimensional-rendered environment. The first GUI might extract an image from the video or animated GIF file. Or the first GUI might use the video or animated GIF file as is, such that the scene includes moving/animated features.
Reply forms may exist in sets. One example set of reply forms is displayed by the Reply Form Selection Window 350 in
The inviter may use the Reply Form Selection Window 350 to customize each reply form (step 207), whether the reply is or is not the chosen one. This customizing might be done by the user sweeping a mouse (swiping) across a passage of text to highlight the passage of passage, and typing (e.g., by using a keypad) text that will replace the highlighted passage. The inviter might use the first GUI to revise the font and size in which each text passage is rendered. This might be done by right-clicking on a text passage to open a formatting window from which to select a font and size for the passage. The GUI may also enable the inviter to move each text passage and each virtual button and each reply field to a different location on the invitation. This might be done by selecting-and-dragging (clicking-and-dragging) the respective text passage or virtual button or reply field. The first GUI may also enable the user to insert one or more of the user-uploaded images into the reply form (image 356). This might be done by the inviter selecting-and-dragging one of the uploaded images to a desired location on the reply form.
At any time during steps 201 through 209, the host might check out the work he/she has done so far. This might be done by opening an interactive “Preview” link, that can be included in any of the windows. In this example, a “Preview” link is part of and that instantly renders and animates any customization/edits the host has made to the invitation so far.
Frame 1 (
By frame 3, ancillary item A has left the FOV, and a portion of the invitation D has entered the FOV. By frame 4, ancillary item B has left the FOV, and a portion of the reply form E has entered the FOV. By frame 5, ancillary item C has left the FOV, and both the invitation D and the reply form E are fully in the FOV. After frame 5, the display zooms in on the invitation D and the reply form E. This might be achieved by each successive frame (in the series), between frame 5 and frame 6, applying a successively (though possibly imperceptible by eye) increase to the zoom until reaching frame 6.
In frame 6, the second GUI enables the invitee to interact with the reply form by inputting (posting) a reply into the reply form E that is in frame 6. The input might be by the invitee selecting (by clicking or touching) one of three virtual buttons F, G, H (to respectively accept, decline or indicate not sure). The input might, if an alternate reply form were selected (by the inviter), include the invitee typing text into a reply field in the reply form. After input by the invitee, one or more follow-on reply forms may be displayed. For example, follow-on reply form 353 may be displayed and filled out if the invitee selects the accept button F. Alternatively, follow-on reply form 354 may be displayed and filled out if the invitee selects the decline button G. And some other follow-on reply form may be displayed and filled out if the invitee selects the “not sure” button H. Interaction by the invitee with the reply form includes the GUI, executed by the invitee's communication device 110b, receiving input (e.g., commands, selections and text) from the invitee.
The panning and zooming in this example, from frame 1 through frame 6, might occur without input by the recipient and as a smooth motion. The invitee's interaction with the reply form E might occur while the reply form E remains in the scene in frame 6, with the tabletop background and ancillary items (food plates J) and the invitation card D and even the invitation card's shadow K still visible.
In this example, the path and the speed (rate) of the panning are controlled by the system 100, and are out of control of the inviter and the invitee. In another example, the first GUI might enable the inviter to use the inviter's input device 114a (e.g., mouse, touch screen, keyboard) to control the path and speed of the panning that the invitee will see. Similarly, the second GUI might enable the invitee to use the invitee's input device 114b (e.g., mouse, touch screen, keyboard) to control the path and speed of the panning.
Different ways are possible for the second GUI to implement the panning-and-zooming display of
The invitation, the reply form, the ancillary items and the background might change parallax with the panning across the scene. For example, a left side of an item but not the right side might be visible during frame 1, whereas the right side of the item but not the left might be visible during a later frame. The invitation or the ancillary item or the reply form might appear to move relative to the background when being displayed. Similarly, a portion (such as a branch of a tree in 331d) of the background might appear to move relative to another portion of the background.
In an alternate example, the invitation is in the form of written text, appearing as though handwritten using a writing instrument on the background (such as engraved into the tabletop of scene 401). And the image of the ancillary item is an image of the writing instrument.
The present method might provide a dynamic digital invitation platform that allows the inviter to utilize existing paper invitation designs and present them on a digital landscape consisting of a photograph of a physical platform, typically a table. The viewport (camera) might scan across the landscape unveiling pieces of the invitation. So in the example of a children's birthday party invitation, the viewer (invitee) might start by seeing a picture of the birthday child laying askew on a table of toys and then the viewport pans (left or right, up or down) to a picture of a paper invitation on the table that shows event details. Then the viewport might scan again and the viewer would then be presented with an opportunity to RSVP.
Another example might use different physical manifestations of the abstraction of the card that provides the details for the party. It could be chalk on a sandwich board or chalkboard, pegged letters on a menu board or lettering on a movie theater marquis. A platform might consist of a movie where the camera pans in 3D space to show different surfaces where the GUI applies the concepts—like a first person film view.
The composite scene, displayed by the second GUI to the invitee, may include interactive content with one or more interactive elements provided by the inviter or provided by the vendor (website). For example, the background might look like the Life board game and a spinner that the end user spins. The composite scene might include the background scene and, in front of (on top of) that would be the invitation, the reply form, and one or more of (i) user image/video, (ii) static ancillary items and (iii) interactive items.
A Technical overview of an example of the scene composition, rendering, and animation techniques might be as follows. In order to achieve photo-realism in our scenes, an invitation renderer (e.g., vendor or inviter) might take photographs of actual blank cards of various shapes and paper types using the identical lighting condition used to shoot our background images. The renderer might then extract out shadow and paper texture from the card photo to create a transparent overlay layer for the card. Using the same templates, the renderer might create clipping paths that crop the rendered cards exactly along the edges of the physical cards. A similar process can be done for in-situ photographs uploaded by the inviter, where the photos are clipped and rotated to be placed on top of a real blank bordered physical photograph. The background, photos, card, greeting texts, clipping path, shadow and texture are then composited into a single scene to be displayed to the invitees. In order to save bandwidth and rendering time, the renderer might use a backend rendering service to pre-generate composite card and email images prior to sending out the invitations. The renderer might generate the images at various resolutions and crop areas to accommodate different devices and screen sizes.
When displaying the invitation to the invitee, the frontend might automatically select the set of pre-generated images closest to the invitee's device screen resolution to minimize the amount of scaling needed, optimizing performance and quality. To help ensure the accuracy of the scene composition and animation anchor frames positions, the renderer might slice background images to 2, 3, or 4 pieces depending on the target device. The slices might be cropped and divided in such a way that the primary elements (the greeting texts on animation start and the card on animation end) are centered on the screen. This might enable the renderer to easily accommodate any reasonable browser window size/ratio gracefully. The renderer might render the desktop, tablet, or mobile guest experience depending on device screen size/ratio.
The components and procedures described above provide examples of elements recited in the claims. They also provide examples of how a person of ordinary skill in the art can make and use the claimed invention. They are described here to provide enablement and best mode without imposing limitations that are not recited in the claims. In some instances in the above description, a term is followed by an alternative or substantially equivalent term enclosed in parentheses.
This application claims priority from U.S. Provisional Application No. 62/221,811, filed Sep. 22, 2015, hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62221811 | Sep 2015 | US |
