WO2009082821A1 - Développement de site internet et utilisation de site internet pour des artistes - Google Patents

Développement de site internet et utilisation de site internet pour des artistes Download PDF

Info

Publication number
WO2009082821A1
WO2009082821A1 PCT/CA2008/002297 CA2008002297W WO2009082821A1 WO 2009082821 A1 WO2009082821 A1 WO 2009082821A1 CA 2008002297 W CA2008002297 W CA 2008002297W WO 2009082821 A1 WO2009082821 A1 WO 2009082821A1
Authority
WO
WIPO (PCT)
Prior art keywords
artist
user
module
webpage
providing
Prior art date
Application number
PCT/CA2008/002297
Other languages
English (en)
Inventor
Mark Watkins
Conan Galloway
Original Assignee
Gtn Entertainment, Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gtn Entertainment, Ltd filed Critical Gtn Entertainment, Ltd
Publication of WO2009082821A1 publication Critical patent/WO2009082821A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0603—Catalogue ordering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the present invention relates, in general, to website development and usage.
  • the Internet is widely recognized as an easy to use, convenient communication tool which allows instant world wide communication between people, as well as an advertising and sales medium for various products and services offered by people and companies.
  • Website software developers are available to create a website meeting an individual's expectations, but require a fee and an exchange of ideas with the website owner so as to create a website meeting the user's expectations. Further, once such a website is developed by a third party for a website owner, changes to the website due to modernization, and the addition or revision of products, services and features of the website, require further communication with the website developer thereby adding costs, delays in updating the website.
  • a method for an artist to create a customized webpage featuring works of the artist comprises the steps of: [0009] 1. providing webpage authoring software
  • the method further comprises the step of providing a merchandise module in the web authoring software allowing the artist to display artist related works and products for purchase by users who access the artist's webpage.
  • the method may also include the step of allowing the artist to record music directly on the artist webpage.
  • the method also includes the step of providing the artist webpage with a private portion accessible only by the artist and a public portion accessible by the public.
  • the method may also include the step of providing the user with a personal user webpage and public user webpage and public webpage on the network.
  • the method includes the step of allowing third party users who access the artist webpage to search a list of artist works stored on the artist's public page.
  • the method includes the steps of providing a plurality of distinct artist work genres; assigning a genre to each artist work stored in the artist public page; and providing a search tool enabling a user to search the entire artist works assigned to one genre selected by the user.
  • the method also includes the steps of providing the plurality of selectable genres in a continuous list and providing the user with a selection of a number of genres preceding and succeeding a selected genre on the list of the genres for output to the user upon user selection of one genre.
  • the method of claim 1 further includes the step of providing merchandise for sale from at least one artist to users who accessed the web server.
  • the method also includes the step of providing a merchandise module accessible through the web server containing web pages of a plurality of artists merchandise from any of the artists.
  • Figure 1 is a pictorial representation of a General Site Flow:
  • Figure 2 is a pictorial representation of a site map
  • Figure 3 is a pictorial representation of a general page nav bar (not logged in);
  • Figure 4 is a pictorial representation of a footer bar
  • Figure 5 is a pictorial representation of a general page nav bar (logged in);
  • Figure 6 is a pictorial representation of a nav bar (not logged in);
  • Figure 7 is a pictorial representation of a nav bar (logged in);
  • Figure 8 is a pictorial representation of a login page
  • Figure 9 is a pictorial representation of a registration process required account information
  • Figure 10 is a pictorial representation of an example help window
  • Figure 11 is a pictorial representation of a sample alert dialog
  • Figure 12 is a pictorial representation of a sample confirm dialog
  • Figure 13 is a pictorial representation of a sample input dialog
  • Figure 14 is a pictorial representation of an image browser
  • Figure 15 is a pictorial representation of a home page
  • Figure 16 is a pictorial representation of a search page (search mode).
  • Figure 17 is a pictorial representation of a search page (directory mode).
  • Figure 18 is a pictorial representation of a search page (selected genres).
  • Figure 19 is a pictorial representation of a search page (genre wheel options).
  • Figure 20 is a pictorial representation of a search page (genre wheel interactive version);
  • Figure 21 is a pictorial representation of an about us page
  • Figure 22 is a pictorial representation of a user account information page
  • Figure 23 is a pictorial representation of an user account profile information
  • Figure 24 is a pictorial representation of an user account profile information
  • Figure 25 is a pictorial representation of an image manager (image browser/editor);
  • Figure 26 is a pictorial representation of an image manager (file/folder manager);
  • Figure 27 is a pictorial representation of an image manager (uploaded selection and data entry);
  • Figure 28 is a pictorial representation of an image manager (upload complete);
  • Figure 29 is a pictorial representation of a song manager (main page);
  • Figure 30 is a pictorial representation of a song manager (upload link disabled);
  • Figure 31 is a pictorial representation of a song manager (edit song data, display mode);
  • Figure 32 is a pictorial representation of a song manager (edit song data, edit mode);
  • Figure 33 is a pictorial representation of an upload a new song (step 1);
  • Figure 34 is a pictorial representation of an upload a new song (step 2);
  • Figure 35 is a pictorial representation of mockup of message manager
  • Figure 36 is a pictorial representation of a sample PWP (private mode, one column layout);
  • Figure 37 is a pictorial representation of a Sample PWP (private mode, two column layout);
  • Figure 38 is a pictorial representation of a page layout interface
  • Figure 39 is a pictorial representation of a module layout interface (single column layout);
  • Figure 40 is a pictorial representation of a module layout interface (two column layout);
  • Figure 41 is a pictorial representation of a PWP styles editor (preset style selector).
  • Figure 42 is a pictorial representation of a PWP styles editor (custom style example).
  • Figure 43 is a pictorial representation of a PWP styles editor (color picker).
  • Figure 44 is a pictorial representation of a module edit settings (basic example).
  • Figure 45 is a pictorial representation of a module edit settings (module settings with additional data example).
  • Figure 46 is a pictorial representation of an about us module (wide example);
  • Figure 47 is a pictorial representation of an about us module (left and rights examples);
  • Figure 48 is a pictorial representation of a blog module (wide example).
  • Figure 49 is a pictorial representation of a blog module (left and right examples);
  • Figure 50 is a pictorial representation of a blog module editor
  • Figure 51 is a pictorial representation of a music list module (wide version);
  • Figure 52 is a pictorial representation of a music list module (left and right versions);
  • Figure 53 is a pictorial representation of an image list editor
  • Figure 54 is a pictorial representation of an image viewer module (wide version);
  • Figure 55 is a pictorial representation of an image viewer module (left and right versions);
  • Figure 56 is a pictorial representation of an image viewer module (left version pop-up);
  • Figure 57 is a pictorial representation of a single-song player
  • Figure 58 is a pictorial representation of a site-wide player
  • Figure 59 is a pictorial representation of a recording application mockup
  • Figure 60 is a block diagram of an operating environment for the present website development application.
  • Figure 61 is a block diagram of the web page flow of the web page development application.
  • artists 100 may be any individual or group of individuals who create artistic related works, such as music, video, sculpture, paintings, etc.
  • Non-artist users 102 are non-artist related individuals who wish to view and possibly purchase artist created works and artist related material.
  • the artists 100 and the non- artist users 102 communicate with a home website 110 through individual computer terminal devices, such as computers, PDAs, cellular telephones, or any other input device capable of creating, transferring and/or displaying digital content.
  • the artist 100 and the non-artist users 102 communicate through a distributed computer telecommunication network, such as the Internet 104 with a web server or a web- based computer or computer network 106.
  • the web authoring software and the various artist and non-artist users' works, profiles and data are accessed by the web server 106 from a digital storage media 108.
  • the web server 106 hosts a home website 110.
  • the home website 110 which is maintained by a website operator, contains a personal web page (PWP 112) for each artist 100.
  • the artist personal web page 112 contains an artist personal page 114 and an artist public page 116.
  • each artist 100 has the ability through web authoring software contained or accessible by the web server 106 to create a distinct artist personal page 114 and a distinct artist public page 116 which is accessible by the non-artist users 102 through the home website 110.
  • the general site layout is implemented using a wide structure where most pages are accessible from the home page. Pages can generally be categorized as either general or user pages. General pages are available to all users of the site whether they are registered or not. Site Flow
  • the site flow is maintained in a fashion consistent to website design, utilizing a set of navigation bars as well as a graphic site map.
  • the footer bar found at the bottom of all pages has a link to the site map (see Figure T).
  • This site map has links to most of the major pages in the site.
  • the site map links are constructed at run-time to ensure that if a user is logged in the URL is properly formed or if they are not logged in the link is disabled.
  • a navigation bar found towards the top of the screen. This bar has links to the general pages as well as a login status control which if the user is logged in contains links to both the user's personal web pager (PWP) in private mode as well as the user settings page (see Figure 3 and Figure 4).
  • PWP personal web pager
  • a header navigation-bar is displayed at the top of the screen (see Figure 5 and Figure 6). When a user is logged in, it contains links to the site homepage, site map, user PWP and user settings. When a user is not logged in, the user links are not shown but there is a link to the login page.
  • PWP add songs, buy or sell merchandise the user will need to create a MeAndMic account as well as login to the site.
  • User management is accomplished using a modified version of ASP.NET 2.0 membership manager. Logged in users are checked vs. a session object which will timeout after 15 minutes of inactivity. All login pages are secured using HTTPS.
  • Logged in user page 1, Fig. 2 checks to see if the user is currently logged in and, if not will control redirect to the login page, see Fig. 7. From there a user can login or access the link to create a new account.
  • the potential member enters the required account information, which includes: the user name, password, contact email, security question and answer, see Fig. 8. [0102] Third, the potential member will define some additional information including their account type, mailing list recipient etc. Most of the user data itself can be optional for free accounts and would be entered later from the user data page.
  • help file determines necessary has a help link in the right corner of the title bar. This link will open a Telerik RadWindow in a movable/resizable mode with the given help file, see Fig. 9, loaded into the window. All help windows contain links at the bottom to direct the user to a feedback form as well as to open the help file in a new window formatted for printing
  • dialogs are created using customized Telerik
  • Parameters are passed to the dialog, which can contain: calling object, display message, size restrictions and other data needed to form the dialog. Dialog instances are assigned callback handlers in the parent page, which will process the information client-side or hand the event off to an AJAX handler in the code-behind.
  • User images are stored in a personal user folder, described hereafter. To allow access to these images by the various modules, style and other components, an image browser control is provided.
  • Each image folder see Fig. 13, in the members' personal folder contains an xml file, which has a directory listing of the images, their logical name, path, dimensions, and a description.
  • an image browser control loads, it builds a folder list of all the folders available and adds them to a combo selection.
  • the combo selection is changed, the given folder's xml file is read into a gridview and scripts are assigned to handle previews.
  • the previews create a scaled copy of the image in a temp folder and display that as well as the description.
  • the control When the control is added to a page it can be assigned one or more pairs of controls, which would typically be a hidden and visible textbox for the path and logical name respectively. Accessing the control switches a view and clicking the "Apply" link switches back to the other view and assigns the selected values to the textboxes.
  • a single ad banner can be provided at the top of most pages.
  • This banner can be 975 pixels wide by 100 pixels, tall, for example, like the one shown on the site homepage see Fig. 14.
  • the banner randomly determines which advertisement to place based on a random number generator scaled by the total number of advertisements available.
  • the banner loads a static image, flash movie file or some other media for the given advertisement and where appropriate links the media to the site of the advertiser.
  • All advertisements may be given equal weight on all pages; but the algorithm can be modified to reflect a weighting based on the users indicated preference of advertising categories.
  • the home page shown in Fig. 14 is the default page when accessing the site by an incomplete URL.
  • Implementation is made of individual controls and where each control is modular and independent of each other.
  • the show figure is typical of the perceived future layout with the exception that the two narrow panels to either side of the main content panel will be replaced each with two smaller panels for a total of four. These smaller can change from time to time but can generally include the following:
  • RadRotator control which allows for multiple panes of information. This control can be manually changed but also rotates automatically after a specified time has passed. This information will vary from time to time but will generally include: [0124] 1. Welcome messages.
  • the function of the search page is two-fold. First to find an artist's PWPs that users are aware of but may not know the exact spelling or be aware of the artist's stage name.
  • the second functionality would be to discover new artists altogether.
  • the difference between the "user name” and the "stage name” will now be described.
  • the user name is the unique user ID that is created when at registration and it cannot be changed at a later date.
  • the stage name is what the artist uses logically as their name.
  • the search engine see Fig. 16, is where the various search criteria is set and the results appear in a gridview.
  • the key to the search engine is that users can enter complete or partial stage name or no stage name at all. This would probably be the interface that users would likely use when looking for new groups as they could just set genre and location information and review all the findings.
  • a third mode (not shown) will be a song lookup. This search will be similar to the artist searches except that instead of looking up and sorting by song title. Additional search criterion will include: song type (cover or original), the song author, upload date and average rating.
  • the genre wheel a concept developed specifically for the MeAndMic site, involves ordering the genres in a logical progression similar to a color wheel in graphic design. A user can select a starting genre and then set a range plus or minus that genre. For example if someone likes heavy metal music but wants to broaden their tastes they might try heavy metal plus or minus two, which would be a range of genres from pop to punk.
  • the genre wheel settings can be set by the controls, see Fig. 19, or by way of an interactive flash movie loaded into a Telerik RadWindow, see Fig. 20.
  • the genre wheel selector shown in Figures 19 and 20 is a flash movie that allows the user to graphically select a genre by range and a direction and then feeds that information back to the parent page control.
  • a search is performed using the genre wheel concept using the starting point direction and range.
  • heavy metal is selected as the genre or starting point and a range of +-2 this equates to genre 3+2, this equates to genre numbers, 1,2,3,4,5, this equates to "pop", “rock”, “heavy metal”, “hard core”, “punk” genres, artist stats like total fans and site hits, artist songs stats like average ratings of songs, and play links for the artist selected songs similar to those found in the music list module described hereafter. Learn page
  • a core directive of the MeAndMic mission is to help educate artists in the business of music and to help build the music community across a global base. To this end there is a learn page linked from the general navigation bar that will feature a number of articles.
  • the main control area on the page will contain a Telerik RadTabStrip which will have tabs for the key learn areas which will include: [0146] 1. How-to articles.
  • a site bulletin board allows users to create postings as well as to review and answer these postings.
  • Postings will be controlled based on the user's membership type. A user should be a logged in member of the site to post a listing.
  • the account type can restrict the number of listings per month allowable. For example, there can be two listings for free members and when the paid members are added they will have additional listings available. Users can purchase additional listings if they would like.
  • the listings can viewed using both a directory and search engine approach where the results will be able to be filtered and sorted by: date, title, region, price (where applicable) and topic keywords.
  • the directories can include: musicians wanted, bands wanted, instruments for sale, general equipment for sale, general services wanted/provided and more.
  • Certain categories can have additional media selected from the user's personal folder attached to the message. For example, a musician listing that they are looking for a band (i.e. band wanted) could attach a sound clip from their personal folder as an audition. In other cases like "equipment for sale,” images could be selected from the user's image folders.
  • This page would incorporate a Telerik RadEditor similar to the blog module editor see Fig.
  • Figs. 16 and 17 for example.
  • the creation of a new message will utilize a separate page with a modified Telerik RadEditor similar to the blog module editor, see Fig. 50.
  • “userfiles” is maintained on the site server and all users of the site have a folder, which is the same name as their user ID in this folder.
  • the userfiles folder is kept separate from the site structure to facilitate site updates, backups and recovers situations.
  • Each user folder contains in the root:
  • the mam account information page Fig. 22, is shown as having three catego ⁇ es for example'
  • Membership information which is information specifically about the membership account. This includes functionality to change the user password, email, account type and payment data. This is also where user can toggle whether they want to present a PWP and set an avatar image for feedback and other messages.
  • All data is stored in the database in tables that are related to the core user table by way of the user ID
  • the set of data has a one to one relationship to that user (like the address, stage name etc.)
  • the information is presented in a form control that has a display and edit mode, see Figs. 23 and 24
  • Information is retrieved and set by way of stored procedures.
  • new records are added by way of a single form directly above of below a gridview of all existing records in that table (see the members section at the bottom of Fig. 23.
  • Image File Management Images are stored in the user's personal folder, which is not directly accessible by the user. Instead all interaction including adding new images, editing image information, moving or deletion of images as well as folder management will be handled through a single page.
  • the second view allows the user to manage the folder structure of their image folder as well as move and delete image files, see Fig. 26.
  • the folder tools allow the user to :
  • Telerik's custom HTTP header that breaks uploaded files into smaller portions and reassembles them on the server.
  • the control has been configured to currently allow for a maximum of five image uploads at a time. At the point of selection the image logical name must be set. The destination folder can also be changed at this time while descriptions can later be set in the first view of the image manager.
  • the song file management page is also accessed from the user settings. It provides a single location to upload songs, edit their data, as well as delete and recover songs.
  • Song information is stored in a table in the database, which has a many to one relationship to the main user table. Songs are assigned a unique ID at the point of uploading.
  • the song file name itself is appended with the 'ticks' of the current server date/time in the same way as uploaded images. Additional data stored for a given song would include:
  • the song title which can be limited to 25 characters in length, for example.
  • a reference to an image files in the user personal folder This image will display in various song modules as well as in the player when the track is playing. If an image is not specified the database will assign a placeholder image in the various stored procedures that retrieve songs.
  • a song is deleted its status is changed from active to bin (short for recycle bin), see Fig. 30.
  • free account members can have six active songs and two bin songs at any given time. Bin songs still exist in the user folder but will not be accessible show in the search page, players or modules. Bin songs can be restored to active, assuming that there is room in the active count or permanently deleted. Once permanently deleted from the user's perspective the song no longer exists. The file will actually be kept until the end of the week on the server. This allows the file to be included in day-to-day backups, which will facilitate recovery in certain situations.
  • the message management page provides means for users to receive and send messages to other users on the site as well as to and from administrators of the site. Messages are stored in the database in a concise table with a many to one relationship to the user table.
  • the message type as stated above the message type is stored within the record and message types in the immediate version of the message system will include:
  • Notifications which are messages from the admin staff, typically alert users to site changes and new features.
  • Feedback messages which are messages either from users either as logged in members or anonymously if not, be logged in members. A given comment could only be initiated by a feedback module on a given user's PWP.
  • User messages which can generally only be sent to users who are listed as a fan of a given user to avoid spam issues but could also be the result of a previously sent user message from another user. These would also include mass mailings from users to fan lists for concert notifications, blogs updates and other automated notification features.
  • the message manager is implemented using a number of modified Telerik controls including a RadTree to display the possibilities, a RadTabstrip to categorize the messages and more, see Fig. 35.
  • Many messages would be initiated from sources outside the manager, typically from modules like the feedback module. If, however, messages are created from the manager in the case of user messages, they would be composed using a version of the Telerik RadEditor similar to the blog module editor.
  • the user can use the message manager to toggle feedback messages to indicate whether or not they should appear in the feedback module should one exist of the PWP.
  • Users can also set the priority of one to five of a feedback message to affect its likelihood of displaying earlier in the feedback listing.
  • a fan request would typically be made from an instance of a fan-listing module on the user's PWP. At some point the receiving user would review these requests by way of the message manager. The user can discard requests that they choose to reject, and in the case of approved requests they can reply with a welcome message as well as opt whether or not they wish to send a return request.
  • the owner ID which would also be related to a user ID on the user table but would be the user that the other is a fan of.
  • Users can categorize their fans as they would like in a manner similar to folder storage to allow for customization of which users will be displayed in the module. This will also allow for targeted mail-outs using the message system. For example, a user might create one group for BC based fans and another for Alberta.
  • Playlists can be created from the site-wide player, and this page will allow users to manage these playlists as well as distribute them.
  • Playlists are stored in the database as two tables; the first is a table of the playlists; which stores the id, owning user id, name and description. The second is a table of the tracks of the list which stores the song id, order number of the track and playlist id needed to relate the tables.
  • playlists are 'owned' by a given user, however if the site-wide player is being used by someone who is not logged-in the playlist is still stored as an anonymous playlist. All anonymous playlists use the same reserved user id and are assigned a unique id like any other playlist. The difference is that this id is also stored as a cookie on the user's machine. This way if an anonymous user accidentally closes a player the application will still be able to retrieve the last playlist when they open the window again. Users can have an unlimited number of playlists but the lists themselves are restricted to a maximum of twenty songs, for example for performance loading reasons. [0235] The layout of the manager can be:
  • the personal web page is the core component of the artist marketing tools. It utilizes a modular approach to creating a website presence for the user. Users can create public and private pages and in turn pages can contain public and private modules. The look and feel of the page can be established with no HTML formatting knowledge, [0247]
  • the system checks to see they are the logged in user, as match on the user ID in the URL of the page. If this is the case the page loads in 'private mode' and all pages are shown and all modules on a page are loaded, regardless of whether they are set as public or private. Additionally modules are loaded in private mode, which would typically mean that they would have links to edit the module settings as well as change data, or other functionality depending on the module.
  • Pages are in actual fact stored in a pagelnfo.xml file, Fig. 36, kept in the resources sub-folder of the user's personal folder structure.
  • the xml file is structured as follows:
  • a 'my Pages' node for the pages collection which indicates next ID's for new modules and pages.
  • Each 'page' node is a single page. This node contains a value which is the page id. Each page node has a number of children including
  • Three child nodes to contain module nodes One for the left column, the right column and the wide column.
  • Each column node contains zero or more module nodes.
  • a module nodes has a number of values for the:
  • the module visibility i.e. whether it is public or private.
  • Modules also contain one or more child nodes which are used to configure the parameters set by the module edit settings page. At the very least all modules have a parameter to define the current style applied.
  • pages are configured to be either single or two columns. If they are a single column the modules 'wide' version is loaded which is configured to be
  • the page layout interface shown in Fig. 38, allows for the additional of new pages to the user PWP as well as the movement, deletion, visibility control and renaming of existing pages.
  • a maximum of 10 pages can be added to a user site.
  • New pages are always given a unique name, placed last and are set to private visibility.
  • a page must be empty of modules to be deleted.
  • a page name must be 16 or fewer alphanumeric characters.
  • the first page is always considered to be the default page, i.e. the page that is loaded if someone accesses an incomplete URL.
  • This file is checked whenever a module is added by a user, moved etc. to ensure that the proper controls are utilized.
  • Each module node contains the following: [0278] Values to indicate the module prefix (i.e. short name) and common name.
  • a child node called 'defaultPara' that would contain one or more
  • the module layout page loads from the modReg file all available nodes into the Telerik RadTabStrip at the bottom of the interface. Links to add each module are dynamically creating unless the module can only be added once to the page and has already been added. The action of adding a module will add it to the bottom of the current page and in private mode with style 1 as the default.
  • the default name is a combination of the common name and module id. A maximum often modules, for example, can be added to a given page.
  • Modules can also be moved from page to page.A module can be specified a public or private as well as renamed in the interface. These two options can also be set from the edit module settings interface.
  • a module can be deleted from this interface.
  • the control checks to see if a deletion file is specified in the modReg.xml file. If not then the module is simply removed from the pagelnfo.xml file. In cases where clean-up is required, a deletion handler will do so, deleting data files and records where appropriate (after confirmation by the user).
  • One aspect of the site is to allow users to create a PWP that is stylish, consistent and professional without the need for knowledge of CSS formatting concepts. To this end they can create the look and feel for their PWP using a point and click interface, see
  • a textbox for selecting color values for fonts, backgrounds and lines The user could either enter a hexadecimal color value for or click a link to select from a color picker dialog. This is the only control where the user can enter data directly but it is validated to ensure a properly formed value.
  • the personal web page is constructed of modules selected from the user and placed using the module layout interface. Most modules have versions for left, right or wide column placement as well as public and private modes. Most modules can be placed multiple times either on different pages or on the same page.
  • the settings that define the look and feel of a given modules are accessed from the edit link found in the top-right corner of the title bar of a module in private mode. This causes the edit window to load with the proper control. The user will edit the settings for the given module and save them to return to the PWP.
  • the edit page looks up the module id from the given users pagelnfo data and from there determines the module prefix. This prefix configures the correct control to load.
  • the about module see Figs. 46 and 47, will allow the user to present in a consistent fashion key data about them as a performer.
  • Data includes: stage name, genre, group member(s), and general location information. Additionally the user can add a face/group shot and a biography of the group/artist. Much of this information can be retrieved from the artist profile or created ad hoc as the user prefers.
  • the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings, the following settings also exist:
  • the "About" information is also defined from the edit settings but is stored in a separate xml file in the user's personal resources folder.
  • a given module instance has its own xml file which is determine by use of the module id in the filename. Additional information could include: [0325] 1. The stage name.
  • the about information can be manually entered or populated from a stored procedure from the database.
  • the image is selected by using a standard image browser control.
  • Blog Module
  • the blog module Figs. 48-50 allows users to post weblog (blog) entries.
  • the entry interface is similar to most common word processing or email applications, allowing for standard font and paragraph formatting. Additionally the user can choose an icon from their image directory to precede the blog entry. Entries can be set as "draft" in which case they are only visible to the logged in user. This will allow the user to complete an entry at their leisure. From the public perspective entries can be sorted by date in ascending or descending order.
  • the blog module is completed but some immediate additions will include: the ability to notify "fans" (see below) of new entries automatically, the ability for fans to give feedback to entries and the ability for users to be able to move an entry from one blog module to another should they for example decide to split a blog module.
  • module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings the following settings also exist:
  • the blog entries themselves are stored in the database with the entry itself stored as HTML string with the formatted contained. Each entry has a field that describes the module id it belongs to.
  • the module itself is implemented using a paged gridview control that retrieves the entries based on a stored procedure.
  • the default is to only retrieve non-draft entries, but in private mode only the show drafts checkbox see, Fig. 48, can be toggled to show all entries including drafts. Drafts will never be shown in public mode.
  • Fig. 50 is implemented as a separate page which loads the correct entry based on id passed by URL.
  • the editor is a modified version of the Telerik RadEditor
  • AJAX control The users have standard formatting controls as well as spell checking functionality.
  • Page changes are handled using AJAX to prevent postbacks where possible.
  • the music list module shown in Figs. 51 and 52 gives the user the ability to display the songs maintained in their personal folder on their PWP.
  • the module allows the viewer to see data on the song as well as click a link that will open, if it isn't already open, the player and add the song to the player.
  • the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings, the following settings can also exist:
  • the songs list is maintained in the database and is loaded into a gridview from a stored procedure that retrieves songs based on the user id in the URL.
  • Current data displayed is as shown in Figs. 48-50, but additional information to be displayed once populated can include, total plays, average rating, a link to navigate to the catalog to purchase the given song.
  • a variety of image viewer modules can be developed for the site; but one is the slide show version shown in Figs. 53-56. This module allows the user to create a list of images with descriptions from the existing images in their personal folder. The image viewers may be provided with a different layout. [0355] As with all modules the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings the following settings also exist:
  • the image height This height is tempered by an algorithm that looks at the available width for the image and determines which ratio adjustment is more appropriate.
  • the image would be sized by width.
  • the module settings page has a link which directs to an image list manager, Fig. 53.
  • This interface allows a user to select images from their personal folder by way of a form control which also accesses an image browser control.
  • the image list itself is maintained as an xml file in the user's personal folder with the filename including the module id (much the same as the about module).
  • the list can be edited from a gridview control below the form which gives the functionality to:
  • RadRotator control bound to the xml file Clicking on a image invokes client side scripts which change the displayed image.
  • the feedback module is in most respects laid out the same as the blog module.
  • the feedback module will display user comments that the artist in question has flagged using the message manager.
  • the module also offers a link for users to be able to leave new comments. These new comments would not display until flagged by the artist.
  • the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings the following settings also exist:
  • the entries are presented in a paged gridview, where the content heights and page size are set.
  • the entries as are all messages are stored in the database and retrieved by a stored procedure.
  • all flagged comments will display in a given instance of the modules.
  • a modification can allow for the artist to be able to specify comments to show in a specific instance of the comments module, e.g. comments about a concert could be in one module and comments about an album in another. This would be set from the message manager interface.
  • the fan list module provides a means for the artist to display on their PWP selected fan groups that they have created.
  • the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings the following settings can also exist:
  • Each list can be given a more descriptive name. For example a list 'peers' in the management page could be described as 'Bands I have played with' in the module.
  • the layout of the module will be simple with for each list the description, count of members, add the list of members. Each list would show the stage name of the user as well as the date added to the list. In the case of user's who have a PWP, a link will also be provided.
  • the playlist module allows the user to display selected playlists that they have saved.
  • the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings the following settings also exist:
  • L A toggle as to whether a link will be shown for other users to comment on the lists. This would actually be sent as a user to user message.
  • This information will not be stored in pagelnfo.xml and will instead be stored in a separate data file not unlike the image viewer module and its slide show.
  • the layout will depend on the user. If they select the display option to use the combo selection, then only one list will be shown at a time and will change if the user changes the selection. If the user opts to display the lists one after another then the layout will be very similar to the playlist module. The gridview of the play list will be the same as described in the playlist manager.
  • HTML (General) Module This module will give users the ability to create a module as they would like using either a template approach or the WSYWIG environment provided by the editor. This will allow users to create concert notifications, open calls or any other content that they would like that isn't satisfied by the other modules.
  • the module placement and display settings are stored in the pagelnfo data for the given user. Beside the standard settings, the following setting can also exist:
  • HTML HyperText Markup Language
  • the content will be saved in a data file specifically for each module instance.
  • the user can start from scratch or select from a series of preset templates. If they select a template the user would then simply replace the template content with their own. If a user selects a template when they already have content the content would be replaced (after confirmation).
  • the module layout itself is essentially blank and other than the title bar serves as a container for the content created by the user.
  • the merchandise module allows users with merchandise to display selected items for sale. Links from the module would take a given user to the merchandise catalog filtered for the selected item.
  • [0401 ] There are two versions of a site music player for the site. The first is for immediate deployment and is a single song player, and the second allows the user to add songs to a running playlist as well as save the playlist.
  • Both players are implemented using a pop-up window that is accessible from any page on the site regardless of which page opened it.
  • the pop-up window uses a combination of AJAX, client-side scripting and a Flash Externallnterface to prevent reloads and subsequent song play interruption.
  • the single-song player Fig. 57
  • the player interface is divided into two sections:
  • the single-song player is loaded into a pop-up window typically as the result of clicking on a play link.
  • These links can be throughout the site but most commonly a user would initiate this via an instance of a music list module or from the search page. The process is as follows:
  • the opener function that invokes the player first checks to see if an instance of the player is open. If one is it is used otherwise a new instance is opened.
  • the opener checks to see if the page is available and if it is, the song id is passed and the pop-up proceeds to make a request to the its instance of a Telerik RadAjax manager which retrieves the song data from the database.
  • the song information including image is displayed in the bottom part of the window. A link to the user's PWP is added as well.
  • the player has standard controls to play, rewind and pause the track.
  • the player also has a control to toggle single-play and repeat-play as well as volume controls.
  • the player has display areas to indicate the current track, its play state, and time position.
  • the illustrated player skin is shown in Fig. 57 by example and may take other configurations.
  • the site-wide player shown in Fig. 58 can replace the single-song player in most circumstances.
  • the site-wide is sectioned as follows: [0414] 1.
  • the top left-section has controls to show the data for the current track.
  • the top-right section contains the flash player movie.
  • the bottom contains a Telerik RadTabStrip control which has two tabs:
  • the first contains a grid of the current playlist.
  • the song data section is virtually the same as the single song player except that there is also a control for rating a song. This control will only be active after the song has played at least 75% and will allow the user to submit a rating from one to ten on the song.
  • the rating algorithm will record the IP address of the user as well as set a cookie, both of which will help to limit individual users from loading up votes unfairly. This link will also show for past songs in the playlist so a user can wait for a song to completely play before rating it.
  • the repeat button also has additional states for repeat all, and repeat current song and no repeat.
  • This player has controls to stream but if it is set to play the entire song, it will pre-load the next song in the list as the current song is playing.
  • the current playlist tab will contain the grid of songs in the current playlist.
  • the tab has a control at the bottom to load playlists already saved by the user as well as a control to save the existing song list as a playlist.
  • the grid of songs is quite similar to the one shown in the music list module there are quite a few more features to note:
  • Each artist name is linked to open the artist's PWP in a new window.
  • the gird will be contained in a scrolling division to allow for up to 20 songs in a given playlist. Adding new songs beyond this limit will bump the oldest songs from the list.
  • R&EApp shown pictorially in Fig. 59, that will allow them to:
  • the R&E Application is a separate installed application for which there are both Windows and Mac OS versions.
  • the application interacts with the site via secure interfaces to IIS.
  • the key areas that the application will interface with the server include:
  • An option from the main menu will access a local track list, which will allow the user to delete local tracks, upload them to the server and select the option to synch the online tracks with the local by downloading them to the user's local machine. The user can also use this interface to copy tracks, allowing the testing of effects on multiple versions of the same recording.
  • Local tracks are not immediately accessible such that the user should only be able to play them either through the application or from the website but not through a third- party application or be able to distribute them.
  • one of the three aspects of the application is to record tracks straight from the user's computer using either microphone or line-in jacks.
  • the user would specify the standard data associated with a track on the site.
  • the track and the data would be kept locally until such time that the user removes the local file or chooses to upload it.
  • Another of the three aspects of the application is to record a track karaoke style.
  • the user would first search/browse a list of available karaoke tracks. As mentioned the list is on the user's computer and updated on start-up if need be, however the karaoke track is only downloaded when requested unless it exists in the local cache.
  • the user records karaoke style where a backing track plays and the lyrics are displayed in the application. Otherwise the saving and uploading functionality is the same as the simple recorder.
  • the third aspect of the application is the ability to edit local tracks and add effects. The options offered are:
  • Effects can be applied a track and are saved in the local version. The user can review these changes and then if desired delete the file or upload it to the site using the previously mentioned interface.
  • the venue listing system provides users with a means to look for venues in a specific region determine contact information and evaluate the venues.
  • the system includes a series of table in the database, including a table of the venues and user ratings.
  • the venue table contains the following information: [0455] 1. The name of the venue.
  • the venue table also contains:
  • venues are added the site operator through a secure login. All venues have a status field which will indicate if a venue is active, inactive, unconfirmed and more.
  • the user can filter by genre, city, region, partial name etc. As with the search page the results will be displayed in a gridview. Venues will be linked but venues will not currently have
  • Venue accounts may also be provided to manage their own data in much the same way as the artists.
  • Merchandise management functionality can be provided on the MeAndMic website.
  • An interface allows for secure control of the merchandise process from the user, customer and the site operator's perspective.
  • the user can have an interface to be able to order product, monitor progress, set re-order levels, track inventory and track sales history.
  • the order interface will be done from a discrete set of pages that require a logged in user (potentially with a paid user membership account).
  • the order process will be a step-by-step process
  • Step 1 user selects new order or places re-order from the last three orders made. Re-orders will still go through all steps by the user just needs to click next, they can make adjustments if they like.
  • Step 2 user selects a product and additional information including quantity, model, sizes, colors etc.
  • quantities can be restricted for first-time orders.
  • Products and logistics may include some of the following for example:
  • Step 3 if applicable the user either uploads artwork for approval or picks previous artwork from past orders. At this point the user can see a rough preview of the product.
  • Step 4 user selects whether the product goes into their online stock or is shipped to them.
  • Step 5 user information is entered; this can be retrieved from previous orders.
  • Step 6 price is determined, for example, on
  • Step 7 credit card is processed.
  • CC portal services as well as the legalities of processing orders before artwork approval. As such the order might be processed at this time but the CC not billed until artwork/stock confirmation.
  • Profit calculator will allow the user to calculate based on the purchase prices of products allowing the user to determine break-even points based on sales price
  • Notifications users can set notifications based on product levels etc.
  • Module setup the user will use an edit interface to add a merchandise module to their webpage that shows products that they select for sale with a description and dynamic price. Note: this part may be completed in-house.
  • Sales History allows the user to see sales with a number of criteria including;
  • Step 1 review the current contents of the cart and adjust levels
  • Step 2 enter shipping information, note if the customer is a logged in user this can be retrieve from profile but should be reviewed for accuracy.
  • Step 3 enter payment information, again can be retrieved securely
  • Step 4 upon completion of transaction an email will be sent confirming the transaction. A second email will automatically be sent when order is shipped (see below) Site Operator
  • the site operator interface allows the site operator to manage the supply chain from any location as well as monitor transactions and accounting.
  • the shipping interface will help the shipping/receiving dept to manage tasks.
  • Ordering should be available to facilitate the order process. We would need to be able to print a fax or email a copy of an order to give to the manufacturer/printer. The artwork filename needs to be referenced in this order.
  • Receiving Orders confirmed and placed with manufacturers/printers will queue as pending. When an order is received the receiver can print out a copy of the order placed to match with the receipt. If the order matches there should be tool to automatically update the database, or enter adjustments where there are anomalies.
  • Shipping Orders made by customers will queue as a report to be printed on standard triplicate forms. The shipper would print these as well a label report with address labels. The shipper would pick and ship the order and then be able to update the order as shipped (as is) or with adjustments for backorders.
  • Inventory The warehouse should be able to print filterable product inventories, be able to match the inventories and update the database as necessary. A report of missing product needs to be produce able so that levels can be brought up to accurate ranges.
  • This interface is used by the site operator staff to do the following. It would be accessible either through a web interface or could be done through a installed application although the database would still reside on the web server.
  • Order reports A summary of orders placed and totals for reconciliation with manufacturers/printers billing is needed.
  • Sales reports Daily, weekly and monthly reports should be available to reconcile with Credit Card vendor reports as well as for bookkeeping purposes.
  • Payout reports Monthly reports showing payouts to users who have sold products based on the sales price less the GTE fee and handling charges. Payouts lower than a minimum level can be carried into the next period
  • Tax reports Monthly reports showing taxes payable.
  • the artist interface specifically deals with users who are ordering merchandise through the site operator so that they can sell it from their PWP and/or the site operator merchandise catalog.
  • customer refers to users purchasing products for final sale.
  • advisor is referring to users who are selling those products.
  • Part 1 Ordering Products this part allows the artist to pick from a range of merchandise, upload any artwork, get a sense of the final product and finally place the order in secure manner.
  • Part 2 Inventory Management includes the artist's ability to set prices and packages for the products they are selling. Additional tools will be provided for automatic re-order of specified products.
  • Part 3 Reporting Tools includes the reports accessible by the artist as well as GTE showing order histories as well and sales specifics for a given artist.
  • Step 1 select the products to order
  • Step 2 upload and place artwork
  • Step 3 confirm artist information
  • Step 4 checkout
  • Step 1 select the products to order
  • Sub-step Ia Artists can select a given product from a catalog of products.
  • Sub-step Ib depending on the product there may be a next step where the artist picks from a sub-type. For example:
  • a button might come in more than one size
  • a shirt might be long-sleeve or t-shirt.
  • Sub-step Ic the artist picks the quantities. In the case of shirts, this could include the quantities by size as well as color. In the case of items like stickers the quantities will be selected from preset amounts. In the case of items such as shirts, the total quantities will need to meet certain minimums.
  • Quantities can be restricted for first time purchasers. Additionally, total maximums will also need to be checked versus the artist's current inventory. The goal here is to keep an artist from having uncontrolled levels of inventory with the site operator.
  • Step 2 the items would be in the cart and the user would be directed to move on to Step 2.
  • the selections from Step 1 should be maintained for a reasonable period of time, such as one week. That way if/when the artist comes back to the site they can pick-up from where they left off.
  • Step 2 upload and place artwork
  • Step 1 This should be the logical next step after Step 1. As stated there may be a period of time between these steps as the artist obtains the artwork.
  • Sub-step 2a the artist can select from previously approved artwork. This would bump them to sub-step 2d.
  • Sub-step 2b there will need to be a determination whether this requires process printing (like silk-screening) or ink print (transfers and straight printing). This determination will impact sub-step 2d.
  • Sub-step 2c the artist would upload the artwork from their computer.
  • Sub-step 2d place the art work and/or just preview it. In some cases the artwork may be placed left/right etc. More often though this step will just be a preview of how the artwork looks on the product. In the case of process printing additional data describes which color and the number of colors.
  • the artist will need a notification if the artwork is new that there will be an additional time-period for human review and that they may be contacted for further information.
  • Step 3 confirm artist information
  • Part 3 - step 2 Part 3 - step 2. However, just like the customer spec, this information will need to be validated and confirmed. It can also be changed for billing reasons.
  • Step 4 checkout
  • the product may automatically become available if the artist has set-up pricing.
  • Section 1 Set pricing
  • Section 2 Monitor sales
  • Section 3 Handle inventory
  • Section 1 Set pricing
  • Product Pricing pricing will be allowed within a range specified by the site operator. The minimum will be calculated from the wholesale cost plus site operator's sales profit. The maximum will be set by the site operator.
  • the user can pick a price in this range based on the primary currency, and the approximate equivalent currently amount will be shown.
  • Limits on length based on layout of catalog and module interface can be set. If the user does not set a description, then a default product description will be used.
  • Packages the artist can setup a package of products for one price. E.g. one shirt + 2 buttons.
  • Sales price the artist can set a sales price from an effective date to a fixed date or left open ended. When the product price is shown in the catalog or module, both are shown.
  • Section 2 Monitor sales
  • the user can review sales by volume and by product.
  • Section 3 Handle inventory [0576] The handling of inventory would cover the following features :
  • shirts might be a default of tow left of a given size in inventory but the user might change this to five. No matter what the user sets as the default, they will always be notified when an item is at zero in the inventory.
  • Purchase reports the artist can print recent purchases (within the last month), and summaries of previous months. As with the sales, the artist can request full reports from the archive for a fee
  • Profit reports the artist should be able to print a report by product showing aggregate purchase costs (I.e. use the weighted average method of inventory valuation) vs. sales to date.
  • the Customer Interface specifically deals with users who are purchasing other user's products from the site. To avoid confusion when the term “customer” is used it refers to users purchasing products for final sale. When the term “artist” is used it is referring to users who are selling those products.
  • Part 1 Adding Products - this part includes the display of products for sale including the module(s) on the artist's page as well as a site- wide interface. Additionally this includes the addition of products to a shopping cart system, either session-based or post- session.
  • Part 2 - Reviewing Products this part includes the ability for the customer to review the products that are in their shopping cart, remove products, modify quantities/features or select those products that they wish to proceed to checkout with.
  • Part 3 Checkout this part includes the input or retrieval of customer information (address etc.), the interface with the payment portal and secure processing of the transaction.
  • Part 4 follows-up and Reporting - this part includes the ability for a customer to review their order after the fact as well as the internal controls needed by GTE to process an order successfully.
  • All modules know their unique module ID and from this additional data can be retrieved from either the database or another XML file. Typically if it is the later, this is accomplished by building the ID into the file name. For example, gtab lOOOl.xml where 10001 is the module id. As such, in this case, it makes sense to store the items for a given module in a table which in turn links the products for sale table. This way out of stock and price changes would reflect back in the module. When a product is selected in the module, it is added to a cart or directly to the Customer Interface Merch page.
  • This page is the means by which a customer can view and add to cart products being sold by artists site-wide.
  • the page includes:
  • Product Information such as product type, price filter, and availability. If a customer navigates here from the artist PWP, then the display is already sorted to just the given artists products.
  • the results can also be sortable.
  • aspnet_Users A table created as a part of the standard membership handler
  • UserID uniqueindentif ⁇ er - the primary key of this table and the field used as the foreign key on all related tables
  • UserName nvarchar(256) - the common name of the user, this can be obtained through HTTPContext and typically handed as a parameter to a stored procedure to obtain the UserID,
  • aspnetJVIembership A table created as a part of the standard membership handler
  • UserID uniqueindentif ⁇ er - the foreign key relating to aspnet_Users
  • Email nvarchar(256) - the stored email of the user
  • LoweredEmail nvarchar(256) - a lowercase version of the above
  • tblUserlnfo A separate table created by this site operator. The entry of this information can be optional by users and can be required only for paying users
  • fldRegion varchar(50) - User region, state, province etc,
  • fldCode char(l ⁇ ) - User postal, zip code
  • fldPhone char(l 5) - User phone number
  • fldFax char(l 5) - User fax number
  • fldGenre varchar(256) - a semicolon delimited list of music genres of the artist. The genres are stored as two digit numbers that reflect a static list. E.g. "01 ;03;04" would translate to "Pop;Ska;Punk"
  • User Login It is desirable that all customers be members of the MeAndMic website. To further this; steps can be taken to force users through a registration process or to login. However, users can be allowed to review products without logging in.
  • Product Data the product data should be stored in the database. The table containing product counts and transactions would presumably link to aspnet_Users.
  • the shopping cart can be stored in the database to facilitate users adding products closing the session and then returning at a later time.
  • a given product can have links both to the artist PWP and to the Customer
  • Products can be removed or inactivated. In the case of the latter, the products stay in the cart but would not be processed at checkout.
  • the checkout is a standard system of confirming the products, adding/confirming customer information and connecting with the pay portal.
  • Step 1 A list of the products and a sub-total can be displayed. The customer can link back to the review page to remove or modify products
  • Step 2 The customer information can be obtained from tblUserlnfo. If it is inaccurate it can be changed. The user should be prompted as to whether they want to update their information (if it differs). The actual order information may not be referenced from tblUserlnfo after this point in case the user changes their data between this point and the point of sending the product.
  • Step 3 Once the destination information is retrieved the customer can select the shipping method. The data on this will be gathered for any country. Shipping outside of the country will require human review before confirmation and the customer will be notified of this. In this case Steps 4 and 5 would be modified.
  • Step 4 Connect to the pay portal
  • Step 5 Display printable receipt as well as email confirmation.
  • the site operatory may have a need for daily/outstanding orders to be processed report, or the ability to report sales by customer, including totals and amounts to remit, or have the ability to report on out of stock inquiries.
  • This Interface covers the tools used by the site operator staff to monitor purchases and sales for the purpose of shipping and billing. To avoid confusion when the term "customer" is used it refers to users purchasing products for final sale. When the term "customer" is used it refers to users purchasing products for final sale.
  • This part of the system can be thought of as having four parts: [0644] Part 1 Receiving Management - this part will cover the tools that help the site operator o approve orders, hand them off to the printer/manufacturer and accurately receive the product.
  • Part 2 Shipping Management - this part will cover the tools that help the site operator to process customer orders.
  • Part 3 Inventory Management this part will cover the tools used by the warehouse staff to check inventory levels and make adjustments where needed.
  • Part 4 Accounting and Reporting this part will cover the tools used by management and accounting staff to make sure vendors are paid, customer payments received and artists paid their revenue. Additionally these tools cover tax and governmental reporting requirements the site operator is obliged to make.
  • Step 1 receive order notification
  • Step 2 approval process
  • Step 3 place the order
  • Step 4 receive the product
  • Step 5 notify the artist
  • Step 1 receive order notification
  • Order notification should come automatically to the site operator employee tasked with handling orders (an email account can be setup for this purpose).
  • the order should include:
  • Step 2 approval process
  • the approval process should include:
  • Step 3 place the order [0665]
  • the order from step 1 should be in a form that can be emailed or faxed to the vendor.
  • Step 4 receive the product
  • the receiver When the product is received, the receiver will compare the physical count with the purchase order. The interface will allow them to receive all items into inventory either with one click if everything is present or by item if items are missing or back-ordered.
  • Step 5 notify the artist
  • This part describes the tools that help the site operator to ship the products that have been purchased by users from the site.
  • Step 1 print pending sales
  • Step 2 pick and package sales
  • Step 1 Print Pending Sales
  • the shipper can generate a list of pending sales orders. Orders can be printed more than once but there should be a notice if an order has already been printed. This way if a shipper misplaces a sales order they can reprint it but if they see a notification they can double-check that they are not accidentally sending a second time.
  • the list should be in a pick format where the shipper can check the orders he will pick or a quick button to select all. From here the shipper can generate the invoices as well as generate the mailing labels.
  • Step 2 Pick & Package Sales
  • This interface allows the warehouse staff to confirm actual product levels with system levels. At any time staff can print an inventory list. This list can be filterable by specific artist or letter range of artists (eg all artists from A to E) and /or Product type code.
  • the printed list can have room for the actual count as well as necessary information (product type, color etc.).
  • the printed list also has space for signature and date of the person who performed the inventory.
  • the staff member can make adjustments to the system by calling up the product in question and manually entering the count.
  • This module describes the tools used by site operator management and accounting staff to make sure vendors are paid, customer payments received and artists paid their revenue. Additionally these tools cover tax and governmental reporting requirements the site operator is obliged to make.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Databases & Information Systems (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur un procédé permettant à un artiste de créer une page Internet personnalisée présentant ses œuvres et permettant à des utilisateurs non artistes d'accéder à la page Internet de l'artiste pour visualiser, télécharger et acheter des œuvres et des marchandises liées à l'artiste. Un serveur Internet permet à un artiste de créer une page Internet ayant une partie page Internet privée uniquement accessible à l'artiste et une partie de page Internet de l'artiste accessible au public.
PCT/CA2008/002297 2007-12-27 2008-12-29 Développement de site internet et utilisation de site internet pour des artistes WO2009082821A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US1690907P 2007-12-27 2007-12-27
US61/016,909 2007-12-27

Publications (1)

Publication Number Publication Date
WO2009082821A1 true WO2009082821A1 (fr) 2009-07-09

Family

ID=40823731

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2008/002297 WO2009082821A1 (fr) 2007-12-27 2008-12-29 Développement de site internet et utilisation de site internet pour des artistes

Country Status (1)

Country Link
WO (1) WO2009082821A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130332819A1 (en) * 2010-08-18 2013-12-12 Internet Dental Alliance, Inc. System for unique automated website generation, hosting, and search engine optimization
US10320882B2 (en) 2017-08-29 2019-06-11 At&T Intellectual Property I, L.P. Uniform resource locator discovery and tracking for managing sponsored data
WO2022010491A1 (fr) * 2020-07-10 2022-01-13 Hewlett-Packard Development Company, L.P. Commutation de version d'application

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037258A1 (en) * 2000-04-10 2001-11-01 Isogon Corporation Automated retail website creation
US20060155645A1 (en) * 2005-01-10 2006-07-13 Art.Com, Inc. Image uploading and print-on demand system and method, namely for art and photographs
WO2007019691A2 (fr) * 2005-08-17 2007-02-22 Wideport.Com Inc. Generateur de site web automatique
US20070073596A1 (en) * 2005-09-23 2007-03-29 Alexander Jonathon P Systems and methods for marketing and selling media
US20070239555A1 (en) * 2006-03-28 2007-10-11 Kipton Cronkite Method of marketing, exhibiting and selling artwork

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037258A1 (en) * 2000-04-10 2001-11-01 Isogon Corporation Automated retail website creation
US20060155645A1 (en) * 2005-01-10 2006-07-13 Art.Com, Inc. Image uploading and print-on demand system and method, namely for art and photographs
WO2007019691A2 (fr) * 2005-08-17 2007-02-22 Wideport.Com Inc. Generateur de site web automatique
US20070073596A1 (en) * 2005-09-23 2007-03-29 Alexander Jonathon P Systems and methods for marketing and selling media
US20070239555A1 (en) * 2006-03-28 2007-10-11 Kipton Cronkite Method of marketing, exhibiting and selling artwork

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130332819A1 (en) * 2010-08-18 2013-12-12 Internet Dental Alliance, Inc. System for unique automated website generation, hosting, and search engine optimization
US10320882B2 (en) 2017-08-29 2019-06-11 At&T Intellectual Property I, L.P. Uniform resource locator discovery and tracking for managing sponsored data
WO2022010491A1 (fr) * 2020-07-10 2022-01-13 Hewlett-Packard Development Company, L.P. Commutation de version d'application

Similar Documents

Publication Publication Date Title
US20210224884A1 (en) System, method, and medium for propagating a plurality of listings to geographically targeted websites using a single data source
US6769010B1 (en) Apparatus for distributing information over a network-based environment, method of distributing information to users, and method for associating content objects with a database wherein the content objects are accessible over a network communication medium by a user
US8190491B2 (en) Method, system and computer program product for affiliating content
US8442871B2 (en) Publishing user submissions
US7917391B2 (en) Integrated marketing portal for businesses
US20020069108A1 (en) Apparatus and method for online fundraising
US8719041B2 (en) Method and system for customizing a network-based transaction facility seller application
US20070073596A1 (en) Systems and methods for marketing and selling media
US20110184828A1 (en) Method and system for providing annotations of a digital work
US20030229554A1 (en) Method and system for composing transaction listing descriptions for use in a network-based transaction facility
WO2003104931A2 (fr) Procede et systeme permettant de programmer des listes de transactions au niveau d'une installation de transactions fonctionnant sur la base d'un reseau
WO2009082821A1 (fr) Développement de site internet et utilisation de site internet pour des artistes
US8234174B1 (en) Method and apparatus for creating custom advertisements
US20080027821A1 (en) Method and Apparatus for Promotion and Distribution of Electronically Stored Information
JP2001331737A (ja) ネットワークシステム及びログイン方法
Rauland Mastering WooCommerce 4: Build complete e-commerce websites with WordPress and WooCommerce from scratch
Williams et al. Learning Magento 2 Administration
Williams et al. Mastering Magento 2: Maximize the power of Magento 2 to create productive online stores
Bangboonrit Site builder: build, market and manage business website with CMS
Wallace WordPress 3 Site Blueprints

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08867643

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08867643

Country of ref document: EP

Kind code of ref document: A1