CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit of U.S. provisional patent application Ser. No. 61/476,411 filed Apr. 18, 2011 and U.S. provisional patent application Ser. No. 61/606,073 filed Mar. 2, 2012.
FIELD OF THE INVENTION
The present invention relates generally to a system and method for conveying information to a user. In particular, the invention is directed to an electronic newspaper.
BACKGROUND OF THE INVENTION
Advances in computer systems have increased accessibility of information in such systems to unsophisticated users. Advances in display technology, and the capability of computer systems for storing large quantities of useful information, has increased the need for access of such systems by people who do not use them often enough to feel comfortable with traditional information display technology. Intensive efforts are underway in the computer industry generally to find improved ways to display information, and otherwise interact with relatively unsophisticated users.
For example, improvements in data storage and display technologies have combined to make an electronic book possible. Various proposals exist for making a device having the approximate size and shape of a hardback book. A goal of manufactures of conventional electronic books or e-readers is typically to display pages on a screen to look like an actual printed book. Such display technologies can be used with traditional computer display screens.
Conventional systems typically use an Adobe® Flash® compatible software as a plug-in application to convey information such as an electronic version of a newspaper to a user through a communication network such as the Internet. However, the use of the Adobe® Flash compatible software limits a tracking of the information being conveyed to the user and is reliant upon an intermediate software (i.e. Adobe® Flash®) to convey the information to the user. Accordingly, certain devices not equipped with Adobe® Flash® software are not able to view the information intended for the user.
It would therefore be desirable to provide a system and method for conveying information to a user which are usable in an intuitive manner by a user without using Adobe® Flash® software. It is further desirable for the system and method to include a user interface that emulates an actual paper reading material such as a book or newspaper, for example.
SUMMARY OF THE INVENTION
Concordant and consistent with the present invention, a system and method for conveying information to a user which are usable in an intuitive manner by a user without using Adobe® Flash® software, wherein the system and method include a user interface that emulates an actual paper reading material such as a book or newspaper, has surprisingly been discovered.
In one embodiment, a system for conveying information to a user, the system comprises: a server receiving a data file representing an image; a software hosted on the server to generate an HyperText Markup Language environment including the image represented by the data file, wherein the HyperText Markup Language environment facilitates the manipulation of the image represented by the data file; and a user interface having a web browser to display the HyperText Markup Language environment to the user, wherein the image represented by the data file is viewable by the user.
The invention also provides methods for conveying information to a user.
One method comprises the steps of: generating a data file representing an image; generating a HyperText Markup Language environment; embedding the image represented by the data file into the HyperText Markup Language environment, wherein the HyperText Markup Language environment facilitates the manipulation of the image represented by the data file; and displaying the HyperText Markup Language environment to the user, wherein the image represented by the data file is viewable by the user.
BRIEF DESCRIPTION OF THE DRAWINGS
The above, as well as other advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiment when considered in the light of the accompanying drawings in which:
FIG. 1 is a schematic representation of a data management system according to an embodiment of the present invention;
FIG. 2 is a screen shot of a log-in page of the system of FIG. 1;
FIG. 3 is a screen shot of a landing page of the system of FIG. 1;
FIG. 4 is a screen shot of a page of the system of FIG. 1 illustrating a single page viewing mode;
FIG. 5 is a screen shot of a page of the system of FIG. 1 illustrating a two-page viewing mode with zoom;
FIG. 6 is a screen shot of a page of the system of FIG. 1 illustrating a full two-page viewing mode;
FIG. 7 is a screen shot of a page of the system of FIG. 1 showing a toolbar;
FIG. 8 is a screen shot of a page of the system of FIG. 1 showing additional control/display features;
FIG. 9 is a screen shot of a page of the system of FIG. 1 showing a section/edition feature;
FIG. 10 is a screen shot of a page of the system of FIG. 1 showing an advertisement; and
FIG. 11 through FIG. 28 are screen shots related to the User Interface that are described in more detail below.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE INVENTION
The following detailed description and appended drawings describe and illustrate various embodiments of the invention. The description and drawings serve to enable one skilled in the art to make and use the invention, and are not intended to limit the scope of the invention in any manner. In respect of the methods disclosed, the steps presented are exemplary in nature, and thus, the order of the steps is not necessary or critical.
Referring to FIG. 1 there is illustrated a data management system 10 according to an embodiment of the present invention. The data management system 10 includes a database 12, a server system 14, and a user interface 16.
The database 12 is in data communication with the server system 14. The database 12 is adapted to store information in an electronic medium. As a non-limiting example, the database 12 includes a plurality of data files 18 having a Portable Document Format (PDF). As a further non-limiting example, the data files 18 represent a replica of a printed material such as a daily newspaper. In certain embodiments, the data files 18 collectively represent a complete edition of a daily newspaper and are categorized by a standardized naming schema. However, it is understood that the data files 18 can have any format such as Portable Network Graphics (PNG) format for selective presentation to a user through a web browser, for example. As a further non-limiting example, the database 12 can include any data including data relating to conveying and displaying information in a HyperText Markup Language (HTML) environment 21 (e.g. an HTML based webpage, a web-based viewable space coded in HTML, and the like).
The server system 14 is adapted to manage a data (e.g. the data files 18) stored in the database 12 and interconnections between the database 12 and various resources not stored on the database 12. The server system 14 may also be adapted to perform operations such as, a user query, a data transfer, a data retrieval, and a data processing, for example. It is understood that other devices may be used to manage the data stored in the database 12 such as a software engine and a software package, for example.
In certain embodiments, the server system 14 includes a software 20. The software 20 includes processor executable instructions to import the data files 18 from a periodic (i.e. daily) or constant feed (e.g. the data base 12). The software 20 includes instructions to convert the data files 18 to a HTML standard with graphic and multimedia objects, XML, RSS or Portable Network Graphics (PNG) format for selective presentation to a user through a web browser 22. The software 20 has instructions to present the data files 18 having the HTML standard with graphic and multimedia objects, XML, RSS or PNG format as objects in the HyperText Markup Language (HTML) environment 21, wherein the HTML environment 21 facilitates the interaction (e.g. the manipulation of the image represented by the data files 18) and tracking of each of the data files 18 that are presented to a user.
The user interface 16 is interconnected to the server system 14 to transfer data between the user interface 16 and the server system 14. As a non-limiting example, the user interface 16 is interconnected to the server system 14 through at least one of a private intranet, a public Internet, a local area network (LAN), a dial-up-connection, a cable modem, and a high speed ISDN line, for example. Other network devices may be used to interconnect the user interface 16 and the server system 14 such as a wireless network, for example. In one embodiment, the user interface 16 is a computer including the web browser 22 and is adapted for data transfer between the user interface 16 and the server system 14. The web browser 22 may be any browser for providing remote user access to the server system 14 such as Windows® Internet Explorer® (IE), Mozilla Firefox, Google® Chrome, Apple® Safari, and the like.
It is understood that the user interface 16 may be any user access device capable of interconnecting to the server system 14 such as a web-capable mobile phone, a personal digital assistant (PDA), and other mobile electronic devices, for example. It is further understood that the user interface 16, may include any number of user access devices, as desired. Any number of user interfaces 16 may be interconnected to the server system 14, as desired.
In use, a periodic or constant feed of the data files 18 is transferred to the server system 16 (e.g. from the database 12). In certain embodiments, the server system 14 converts the data files 18 to a HTML standard page with graphic and multimedia objects. The data files 18 are selectively presented to a user through the web browser 22 of the user interface 16. As a non-limiting example, the data files 18 having the HTML standard, with graphic and multimedia objects, format are presented to the user as objects in the HTML environment 21.
The user can view the data file 18 (representing the replica of the pages of the daily newspaper) on any browser-enabled device (e.g. user interface 16) without the use of the Adobe® Flash® formatted software. The HTML environment 21 allows the user to navigate to the data files 18 representing any portion of the collective data such as section fronts, pages, previous archived editions, and the like. The HTML environment 21 also provides a page viewing experience including: mouse following, keyboard/mouse support for page up and down scrolling, email features, search features, and customized viewing preferences such as mouse clicks for zoom in and out, for example. The HTML environment 21 allows the user to have full interaction with each page of the daily newspaper (represented by the data files 18) while providing data tracking to a browser-based analytics, now known or later developed. User tracking relative to various ones of the data files 18 presented through the web browser 22 can provide a feedback that is not currently available in the Adobe® Flash® format.
FIG. 2 illustrates a registered subscriber log-in page 24 that is displayed on the user interface 16. Subscribers (i.e. registered users) enter credentials on the log-in page 24 to gain access to the data files 18 (e.g. the image(s) represented by the data files 18). Once the credentials are verified and accepted by the server system 14, an initial landing page 26 is displayed on the user interface 16, as shown in FIG. 3.
Referring to FIGS. 3-6, the landing page 26, as well as other pages, can typically be presented to the user as a single page (shown in FIGS. 3-4), a two-page reader spread with zoom (shown in FIG. 5), or a full two-page spread (shown in FIG. 6). FIG. 3 shows the landing page 26 as the first page of the newspaper. FIG. 4 shows another page 26a that is page 2 of Section A of the newspaper. FIG. 5 shows the two-page reader spread with zoom as a portion of the page 26a and a portion of a third page 26b that is page 3 of Section A. FIG. 6 shows the full two-page spread 26c. It is understood that the user can select a viewing mode to control the manner in which the images/pages are presented on the user interface 16. As a non-limiting example, a front page (i.e. cover) of any publication represented by the data files 18 is displayed as a single page viewing mode since there is no facing page. However, any image or publication represented by the data files 18 can be viewed in a single page or a two-page viewing mode. As a further non-limiting example, each image displayed on the user interface 16 is automatically sized to a space provided by a window of the web browser 22. It is understood that other formats and viewing controls can be provided to the user.
Referring to FIGS. 7-8, a toolbar 28 and a plurality of navigation features 30 can be accessed from the landing page 26 and from all other pages or data files 18 representing pages. As a non-limiting example, the following tools can be made available to the user: 1) Go to HOME or the Initial Page View Mode; 2) BACK one page; 3) FORWARD one page; 4) SEARCH; 5) Email; 6) 2-page Full Height and Width View; 7) 2-page Wide View; 8) 1-page Wide View; 9) 2-page Single Page Wide View; 10) Reduce page magnification; 11) Increase page magnification up to 400%. It is understood that other tools and navigation controls can be made available to the user.
A plurality of page advance arrows 32 (e.g. arrows on the on the left and right of the viewable area 26d in FIG. 8) can be selectively engaged by the user to navigate through the data files 18 or images represented by the data files 18 in a sequential manner.
In certain embodiments, mouse-following navigation is enabled, wherein the user can navigate through the data files 18 or images presented by the data files 18 by moving the mouse in a right-left (previous page) or left-right direction (next page). Portions of the page in a non-viewable area of the user interface 16 can be accessed by moving a cursor of the mouse toward the non-viewable section. Accordingly, the image presented on the user interface 16 is manipulated to allow a user to view previously non-viewable section of the page. As a non-limiting example, a mouse wheel can be engaged to scroll and/or zoom. In certain embodiments, the user can access additional navigation and control features by moving the mouse or pointer to an edge of the window of the web browser.
As shown in FIG. 9, a section/edition feature 34 is presented along a periphery of the view space of the web browser 22. The users can select an appropriate section or edition 26e of the printed publication represented by the data files 18 by selecting a thumbnail representation of the associated data file 18 or portion of the data file 18. It is understood that other means for quickly navigating between sections and editions of the publications represented by the data files 18 can be used.
As shown in FIG. 10, an advertisement 36 can be conveyed to the user through the user interface 16. As a non-limiting example, the advertisement can be embedded in the HTML environment 21 and customized in a conventional manner. It is understood that the advertisements 36 embedded in the HTML environment 21 can be configured to disappear from the user interface 16 after a pre-determined time period.
In certain embodiments, the system 10 conveys information associated with the data files 18 to the user, wherein the information includes accessible hyperlinks that can be selected by the user to re-direct the user from the HTML environment 21 to another webpage.
The system 10 and method of the present invention provides an accurate and complete electronic rendition of the newspaper and other publications. The system 10 and method of the present invention are usable in an intuitive manner by a user without using Adobe® Flash® software and without requiring specific user training or instructive documentation.
The above description of a system and method for an electronic newspaper is included in the co-pending U.S. Provisional Patent Application Ser. No. 61/476,411 filed Apr. 18, 2011. The following relates to improvements in that system and method.
The system according to the invention utilizes a modified version of the Libercus Content Management System available from E. Viddal & Associates, 1413 S. Howard Avenue, Suite 220, Tampa, Fla. 33606. All access to the system database and functionality is accomplished through a standard web browser. Supported browsers include: Firefox versions 3.6 and later; Safari versions 5.0 and later; Google Chrome versions 10.0 and later; and Internet Explorer versions 8.0 and later. Supported operating systems include any operating system on which the above browsers are supported. To access all the system functionality, the incoming connection to the client machine should support a minimum speed of 3 Mbit download and 1 Mbit upload.
The basic requirements for page layout include: 1) Associating a story with a page; 2) Viewing stories assigned to a page; 3) Associating stories with shapes on page; 4) Shapes, defined; 5) Text editing and the database; and 6) Jumps. Under requirement 1), a user must be able to associate a story to a page from a Stories list or a Budgets list. The user must be able to associate a story to a page from within the page layout program. Assigning a Story to a Page will cause that story to take on a Page Link Status of “Assigned to Page”.
Under requirement 2), from within the page layout program, the user is able to view the Slug data for Stories that are assigned to the page currently in use. From within the Pages list window in the UI (user interface described below), the user is able to view the Slug data for the stories assigned to a selected page.
Under requirement 3), the user is able to execute the following steps to place a story on a page: 1) Draw a text box on a page that is pre-loaded with the wanted typography, resulting in a Shape; 2) Modify the wanted typography by right-click and selecting pre-configured choices; 3) Drag story from the list to the specified shape. The story will assume the typography based on the user\'s instructions provided when drawing the shape; 4) Assign a pre-defined shape to the story in the User Interface; and 5) Drag a story from the Stories list in the page layout program to the wanted x-y position on the page. The story assumes the typography based on the selected shape. The act of linking a story to a shape will cause the story to assume the Page Link Status of “Linked to Shape”.
Under requirement 4), a Shape will consist of the following data:
a. Header styles: Style sheets that define the header typography, as follows: Label; Headline; and Deck.
b. Body styles: Style sheets that define the body typography, as follows: Byline; Byline credit; and Body.
c. Caption styles: Styles that define the caption typography, as follows: Caption credit; and Caption.
A Shape may also include: x-y coordinates for placement on a page; Total box depth; and x-y position of standing elements (photos, column sigs, fact boxes) relative to the entire shape.
Under requirement 5), the user is able to edit text on the page using tools provided by the page layout program. These edits must be committed to the database by a prescribed command. Examples:
a. Saving the Page document.
b. Clicking away from the edited story.
An indicator advises the user when changes are being written to the database. When text in a story with Page Layout Status “Linked to Shape” is edited in the text editor, those changes are reflected on the page. The user is advised that a story has been updated by another user. Updating a story\'s text on a page from the database is a user action.
Under requirement 6), it is possible for a story to start on one Page and finish on another page. This condition is hereafter known as a Jump. It is possible for a story to jump over several pages. The user will execute the following steps to jump a story: 1) Select the wanted story on the front page and execute “Create Jump” command; 2) Fill in a dialog box with the wanted jump page, jump words and jump shape; 3) Upon clicking OK, the jump line is created on the front page, automatically reflecting the wanted jump words and entry for the jump page, and the story\'s jump is assigned to the jump page in the wanted shape; 4) Upon placing the jump story on the jump page, the jump shape will contain the wanted jump words and page from which the story was jumped; and 5) Any changes to text that affect the flow of the jump is reflected on both the front page and all jump pages.
Document creation involves templates. Page templates are created using the web interface and stored as HTML documents in the database. These templates are used as the basis from which daily pages are created. The templates contain the publication\'s style sheets and layers. One layer is reserved for Ads. A template may contain predefined shapes to which stories may be assigned as described in the page layout basic requirements described above. The system receives the ad manifest from the ad layout system. The manifest must include the following information for each page: Publication date; Section letter; Page number; Wanted template (optional; if this information is not present, a default template will be referenced in the database and used to create the page); x-y position of each ad; Height and width of each ad in a common unit of measure (points, millimeters); and Filename and file path of each ad.
The system is able to receive ad manifests from any ad layout system which can provide the above information. Libercus will convert the information into a single LibercusAdXML format. This data will be read into the Libercus database. This information will be used to create the page objects with proper ad placement. Links are created to ad files using the path/filename provided by the ad layout system. If the ad file does not exist, the box will still be linked to that file. When a page is opened by a user, the system will poll the file system to determine whether ad files are present. When the ad file is found, it will be linked to the box and shown without further user intervention.
The Ad layer may or may not be locked by default. This will be a system setting. A naming convention is stored in the database, and this naming convention is used to create the file names for each page. This naming convention is provided by the Customer, and will in most cases correspond to the naming convention required by the customer\'s computer-to-plate or output system. During the processing of the ad manifest, the system checks to determine whether a file name that corresponds to the wanted page already exists. If it is found to exist, the system will not overwrite the existing file. It will simply change the ad information as directed by the new manifest.
Users may create pages in advance of the arrival of the manifest from the ad layout system. It will be understood that these page will not be for output and will not be created in place of pages for that publication date. The user clicks “Advance Page” in the Pages list window. A form will be presented to the user, asking for: Publication date (mandatory field, calendar); Name (freetext field, 32-character maximum); and Template name (dropdown, contains the names of existing templates). Upon clicking OK, the document is created based on the requested template with the name provided by the user. It will be saved on a path known to the database. The user may work on an advance page using the same methods used to work on pages created by the system. The user may send an advance page to proof output, but may NOT send an advance page to final output. The user may link an advance page to a production page. Upon opening this page, all work done on the advance page will be linked to the production page. The desired workflow from this point will be that the advance page will cease to exist and that all work done from this point will be done on the production page.
Pages carry workflow statuses that correspond with the page\'s readiness for publication. Those statuses are defined as follows: New; Advance; Working; Ready for Proofing; Approved; Output; and Archived. New is a Production Page\'s status upon creation. Advance is an Advance Page\'s status upon creation. Working is automatically applied and refers to opening a page in the page layout program that automatically changes the page\'s status to Working. Ready for Proofing is manually applied and refers to when all of the stories on a page have reached the status Approved, the user marks the page Ready for Proofing. Approved is manually applied and refers to when the page has been approved for publication, the user marks the page Proofing Complete. Output is automatically applied and refers to when the page output process has been successfully completed, the page\'s status automatically changes to Output. Archived refers to at a time set in the system\'s administrative setting, all pages that have reached the status of Output will automatically change to Archived. These pages, and all stories placed on these pages, are locked for further editing. The page may be unlocked by a user with appropriate permissions.
The Pages interface contains a visual thumbnail representation of the Page\'s workflow status and the workflow status of each story placed on each page.
Automatic image processing workflow involves PDFs for output being submitted to the image processor for CMYK or grayscale pages as directed by the output process. The appropriate profile is attached to each image and the image is converted to the appropriate color space. PDFs submitted for eBlade output will not be color processed. The images remain as RGB on each page.
Manual image processing workflow involves images being submitted to a file system folder for manual processing.
Proofing workflow—A page may be printed from the page layout program to a local printer at any time. The system uses the page layout program\'s process for proof printing.
Output workflow—A page must have reached the workflow status Approved before it may be submitted to the final output process. The system uses the page layout program\'s process for exporting to PDF. The system uses the customer\'s prescribed output naming convention for the PDF\'s file name. The system routes the PDF to the appropriate image processing channel. The system routes the processed PDF to the final output folder for the customer\'s RIP. If an error occurs at any point of the process, a visual indicator appears in the Pages interface and the file is routed to an error folder.
Roles exist to provide default access rights/functionality to a group of users (Group). When a Group is created, it must be assigned to a Role. The User Roles are hard-coded and are not configurable. A System Administrator is able to create new sites. The System Administrator has access to the functions under the System Administration menu in the user interface. A Staff user will have access to the site\'s admin interface. Users created by user-generated functions have the role of a Site User.
A Group is assigned to a Role. When a User is created, it is assigned to one or more Groups. The following groups may exist by default: Site administrators (Role: System Administrator); Content creators (Role: Staff); Editors (Role: Staff); and Site users (Role: Site Users). A Site Administrator may create a new Group by copying an existing group. A Site Administrator may configure the permissions assigned to a Group. If a User is a member of multiple Groups, all Group permissions are combined.
A User login is required to access functionality of the system. A User may be created in the interface and assigned to a Group at the time of creation. A User may be created outside of the interface. A user created in this manner will be assigned to the Site Users group. A user will be identified by the following metadata: User name; Display name; and Nickname. The User name is what the user will use to log in and has the following requirements: Mandatory; Maximum 32 characters; Must be unique; Allowed characters: a-z, A-Z, 0-9; and NOT case-sensitive. The Display name is what is shown on the Welcome page (for Staff and System Administrator users) and on the web site (for Site Users). For Staff users, the Display Name is the value that populates the Byline field upon creation of a new Story. The Display name has the following characteristics: Mandatory; Maximum 64 characters; and Allowed characters: a-z, A-Z, 0-9, hyphen, apostrophe, space. The Nickname is what will display for Site Users when posting Sermo comments. The Display name has the following characteristics: Optional, if not chosen, default is Display Name; Maximum 64 characters; and Allowed characters: a-z, A-Z, 0-9, hyphen, apostrophe, space.
User permissions are inherited from the Group(s) to which the User is assigned. If a User is assigned to multiple Groups, permissions will be combined. User preferences are set in the interface by Users who are members of Groups other than Site Users. The following User preferences may be set in the interface: 1) Columns chosen/not chosen per content type (see User Interface Functional Requirements above); 2) Arrangement of columns in content type list window; 3) Preference for Count in list windows; 4) Preference for default channel when viewing story list; 5) Default Page upon login to UI (Dashboard, Stories, Pages, Media Files, Congero, etc.); 6) Metadata fields to be shown in the Print-Friendly view for Budgets; 7) Date-time display in list windows; 8) Password; and 9) Default section upon content creation. System default will be No Section.
It must not be possible for multiple users to have the same User Name or Nickname. If a user attempts to use an existing user name or nickname, the field is highlighted and the user is presented a message: “(Username or Nickname) exists. Please choose a different user name.” The password validation is required upon creation. “Enter password” and “confirm password” must match in order for the user to be allowed to continue. If the confirm password does not match, the “Confirm Password” field is highlighted and the user is presented a message: “Passwords do not match. Please re-enter the correct password.” The Password requirements are: 6-24 characters; Allowed characters: a-z, A-Z, 0-9, underscore, hyphen, $, @; and Case-sensitive.
Access control is defined at the Group level. A User\'s access rights and permissions will be based on Group membership. Upon the creation of the site, the default Groups will have all permissions by default. A System Administrator may remove permissions as desired by unchecking the appropriate checkbox. A Group may be given access to create, modify and/or delete at the following levels: 1. Content type; 2. Section. Workflow status may also govern access to content within a particular content type. It is possible to grant a Group access to an item of a specific status.
A Channel defines for which content platform a Story is intended. All content other than Stories is considered channel-independent. A newly created site has two channels by default. Channel 0 is named “Web” and Channel 1 is named “Print.” New channels may be created by users with the Role of System Administrator. Channel configuration is a System Administration setting. A Channel must be given a meaningful Name. This Name will appear in the Channel menu selectors. Upon creation, a channel may be designated as a Print channel by clicking the “Is Print Channel” checkbox. Content assigned to a Print channel content is subject to the following behavior: System default publication date for content of Print channel is “Tomorrow”; and Content designated as Print channel content will be subject to archiving as detailed above.
Sections may be assigned to one or more Channels upon creation. By default, all sections will be assigned to Channel 0 upon creation. When a user selects a Channel in the UI channel selector, the Section dropdown will populate with only the Sections assigned to that Channel. When a user assigns a Story to a Channel, only the sections available for the Channel will be presented in the selector in the Channel\'s Properties window. A Section is a method for categorizing content. Sections may be created by users of the Role of System Administrator. Sections are configured under Site Administration settings.
Section functionality is extended wherein a Section may be assigned to one or more Channels. All sections are assigned to Channel 0 (Web) by default. By default, a newly created Story is not assigned to a Section. A Story not assigned to a Section will behave as follows: May not be assigned to a Workflow Status other than “Draft”; Will not be shown in a Budget view; and Will by default be accessible only to the user who created it and users of Role of System Administrator.