[go: up one dir, main page]

WO2009082821A1 - Website development and website usage for artists - Google Patents

Website development and website usage for artists 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
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CA2008/002297
Other languages
French (fr)
Inventor
Mark Watkins
Conan Galloway
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GTN ENTERTAINMENT Ltd
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/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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 OR CALCULATING; 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 OR CALCULATING; 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 creation or management
    • 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

A method for an artist to create a customized webpage featuring their works and enabling non-artist users to access the artist webpage for viewing, downloading works, and purchasing artist related works and merchandise. A web server allows an artist to create a website having a private artist only accessible webpage portion and a publicly accessible artist webpage portion.

Description

WEBSITE DEVELOPMENT AND WEBSITE USAGE FOR ARTISTS
BACKGROUND
[0001] The present invention relates, in general, to website development and usage.
[0002] Artists of many types, including the musicians, painters, sculptors, etc., typically encounter difficulty when first starting their artistic career in having their works recognized by the public. Artists also encounter difficulty when first starting their careers to find a market place to present and sell their works.
[0003] 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.
[0004] Although practically anyone with a sufficient amount of time, study, knowledge and experimentation can write the software code to create an Internet web page, such webpage development typically takes considerable amount of time. In addition, the person trying to develop his or her own website does not have up-to-date knowledge of website design techniques so as to be able to create an efficient, easy to use, well prepared website on the first try.
[0005] 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.
[0006] In addition to these difficulties, artists may not want to spend the time to acquire the necessary knowledge to create and manage a website themselves or have knowledge of the technical skills required for website development so as to be able to easily communicate with an outside website developer.
[0007] Thus, it would be desireable to provide a means or tool for artists to be able to use the Internet to easily market themselves, deliver their works and otherwise earn a living from their trade while enabling the artists to maintain a maximum level of control over their artistic direction. SUMMARY
[0008] A method is disclosed for an artist to create a customized webpage featuring works of the artist. The method comprises the steps of: [0009] 1. providing webpage authoring software
[0010] 2. providing access to the web software through a computer network; and
[0011 ] 3. in response to an artist request for one of creating and editing an artist webpage, providing one of selection and editing of a webpage layout, modules within the webpage, webpage style creation and artist information display.
[0012] 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.
[0013] The method may also include the step of allowing the artist to record music directly on the artist webpage.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
BRIEF DESCRIPTION OF THE DRAWING [0021 ] Various features, advantages and other uses of the present invention will become more apparent by referring to the following detailed description and drawing in which:
[0022] Figure 1 is a pictorial representation of a General Site Flow:
[0023] Figure 2 is a pictorial representation of a site map;
[0024] Figure 3 is a pictorial representation of a general page nav bar (not logged in);
[0025] Figure 4 is a pictorial representation of a footer bar;
[0026] Figure 5 is a pictorial representation of a general page nav bar (logged in);
[0027] Figure 6 is a pictorial representation of a nav bar (not logged in);
[0028] Figure 7 is a pictorial representation of a nav bar (logged in);
[0029] Figure 8 is a pictorial representation of a login page;
[0030] Figure 9 is a pictorial representation of a registration process required account information;
[0031 ] Figure 10 is a pictorial representation of an example help window;
[0032] Figure 11 is a pictorial representation of a sample alert dialog;
[0033] Figure 12 is a pictorial representation of a sample confirm dialog;
[0034] Figure 13 is a pictorial representation of a sample input dialog;
[0035] Figure 14 is a pictorial representation of an image browser;
[0036] Figure 15 is a pictorial representation of a home page;
[0037] Figure 16 is a pictorial representation of a search page (search mode);
[0038] Figure 17 is a pictorial representation of a search page (directory mode);
[0039] Figure 18 is a pictorial representation of a search page (selected genres);
[0040] Figure 19 is a pictorial representation of a search page (genre wheel options);
[0041] Figure 20 is a pictorial representation of a search page (genre wheel interactive version);
[0042] Figure 21 is a pictorial representation of an about us page;
[0043] Figure 22 is a pictorial representation of a user account information page;
[0044] Figure 23 is a pictorial representation of an user account profile information
(display mode);
[0045] Figure 24 is a pictorial representation of an user account profile information
(edit mode);
[0046] Figure 25 is a pictorial representation of an image manager (image browser/editor); [0047] Figure 26 is a pictorial representation of an image manager (file/folder manager);
[0048] Figure 27 is a pictorial representation of an image manager (uploaded selection and data entry);
[0049] Figure 28 is a pictorial representation of an image manager (upload complete);
[0050] Figure 29 is a pictorial representation of a song manager (main page);
[0051 ] Figure 30 is a pictorial representation of a song manager (upload link disabled);
[0052] Figure 31 is a pictorial representation of a song manager (edit song data, display mode);
[0053] Figure 32 is a pictorial representation of a song manager (edit song data, edit mode);
[0054] Figure 33 is a pictorial representation of an upload a new song (step 1);
[0055] Figure 34 is a pictorial representation of an upload a new song (step 2);
[0056] Figure 35 is a pictorial representation of mockup of message manager;
[0057] Figure 36 is a pictorial representation of a sample PWP (private mode, one column layout);
[0058] Figure 37 is a pictorial representation of a Sample PWP (private mode, two column layout);
[0059] Figure 38 is a pictorial representation of a page layout interface;
[0060] Figure 39 is a pictorial representation of a module layout interface (single column layout);
[0061 ] Figure 40 is a pictorial representation of a module layout interface (two column layout);
[0062] Figure 41 is a pictorial representation of a PWP styles editor (preset style selector);
[0063] Figure 42 is a pictorial representation of a PWP styles editor (custom style example);
[0064] Figure 43 is a pictorial representation of a PWP styles editor (color picker);
[0065] Figure 44 is a pictorial representation of a module edit settings (basic example);
[0066] Figure 45 is a pictorial representation of a module edit settings (module settings with additional data example);
[0067] Figure 46 is a pictorial representation of an about us module (wide example); [0068] Figure 47 is a pictorial representation of an about us module (left and rights examples);
[0069] Figure 48 is a pictorial representation of a blog module (wide example);
[0070] Figure 49 is a pictorial representation of a blog module (left and right examples);
[0071] Figure 50 is a pictorial representation of a blog module editor;
[0072] Figure 51 is a pictorial representation of a music list module (wide version);
[0073] Figure 52 is a pictorial representation of a music list module (left and right versions);
[0074] Figure 53 is a pictorial representation of an image list editor;
[0075] Figure 54 is a pictorial representation of an image viewer module (wide version);
[0076] Figure 55 is a pictorial representation of an image viewer module (left and right versions);
[0077] Figure 56 is a pictorial representation of an image viewer module (left version pop-up);
[0078] Figure 57 is a pictorial representation of a single-song player;
[0079] Figure 58 is a pictorial representation of a site-wide player;
[0080] Figure 59 is a pictorial representation of a recording application mockup;
[0081] Figure 60 is a block diagram of an operating environment for the present website development application; and
[0082] Figure 61 is a block diagram of the web page flow of the web page development application.
DETAILED DESCRIPTION Overview of Site Structure [0083] Operating Environment
[0084] Referring first to Figs. 60 and 61 there are depicted block diagrams of an operating environment for a website development and usage application, particularly suited for use by artists to create, store and offer their works to the public. [0085] As defined in greater detail hereafter, 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.
[0086] 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.
[0087] Referring now to Figure 61, 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. As described hereafter, 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. [0088] 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
[0089] 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.
[0090] Besides page-to-page links, users have three main ways to get their bearings and navigate to the desired page.
[0091] The footer bar found at the bottom of all pages (see Figure 15) 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.
[0092] On the general pages there is 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). [0093] For most of the user pages as well as PWP in both public and private modes 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.
General Site Components and Concepts
[0094] If a viewer of the site wishes to view articles, artist personal web pages (PWP) and listen to music they do not need to create or login as a member of the site. To maintain a
PWP, add songs, buy or sell merchandise the user will need to create a MeAndMic account as well as login to the site.
[0095] 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.
[0096] 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.
[0097] Whenever the PWP is accessed for a given user, the currently logged in user is checked. If that user matches the id for the page then the page is loaded in private mode, otherwise the public page is loaded.
[0098] Login status is visually available in the various navigation bars as described hereafter.
[0099] The registration process involves three steps
[0100] First, the potential member has to agree to the terms of service, which include a commitment to adhere to copyright, and intellectual property laws.
[0101] Second, 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.
[0103] All accounts can be free. This third step of the registration process will include the data entry of required information for paid accounts should the user choose to select that option. This would include their legal name, physical address and payment information. [0104] Help Files [0105] A comprehensive and consistent help system is in place. Instead of a FAQ or other large document implementation, concise help topics for the immediate page are accessible.
[0106] Any component where the 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
Dialog Interfaces
[0107] To achieve a consistent look and feel through the site, browser based dialogs have been replaced by customized dialogs. The dialogs are created using customized Telerik
RadWindows that load the dialog file in a modal state, "graying out" the page, see Figs. 10,
11 and 12. 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.
Image Brower
[0108] 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.
[0109] 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. When an image browser control loads, it builds a folder list of all the folders available and adds them to a combo selection. When the combo selection is changed, the given folder's xml file is read into a gridview and scripts are assigned to handle previews.
[0110] The previews create a scaled copy of the image in a temp folder and display that as well as the description. 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.
Ad Rotator
[0111] 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.
[0112] 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.
General Site Pages
[0113] The following pages are accessible to all viewers of the site whether they are a logged-in user of not. Most pages are laid out utilizing a modular pane approach. Typically this would be constructed of:
[0114] 1. Either a user navbar or a general navbar at the top, see Fig. 14,and a footer bar at the bottom, see Fig. 15;
[0115] 2. An ad rotator at either just above or below the navbar, see Fig. 14.
[0116] The primary content in either a 700px pane with room for a series of supporting 250px panes for notifications, etc. see Fig. 21 for an example or the content will take up the entire area in a 975px pane see Fig. 38 for an example.
[0117] While most pages will follow this form some, such as the home page, may be presented in a three column (250px -> 425px -> 250px) format.
Home Page
[0118] 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:
[0119] 1. Top ten lists made of based both on aggregate song ratings as well as PWP hits.
[0120] 2. Featured artists, which will link to the given artist's PWP.
[0121] 3. Links to current contest and promotion pages.
[0122] 4. Links to featured articles.
[0123] The main content area shown in the middle Fig. 14, contains a Telerik
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.
[0125] 2. New feature notifications and other MeAndMic news.
[0126] 3. Hints and tips.
[0127] 4. Contests and promotional information.
[0128] 5. Featured sponsors.
Search Page
[0129] 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.
[0130] 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.
[0131] For example, there could be several bands in different markets with the same name. Perhaps there is a group "The Band" from California as well as a totally different group called "The Band" from the United Kingdom. One group's ID might be "theband_32" and the others might be "the band". When fans of either group would search they would use the same stage name but will still be able to identify which group they are looking for from the additional information; namely, the location information and genre listed.
[0132] More detail on how the user data including the stage name is set can be found in the following description.
[0133] There are three basic modes for the search page:
[0134] 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.
[0135] Directory lookups shown in Fig. 17 would be similar in most respects to the search engine except that the user can navigate by the first letter of the artist's stage name
(like a phone directory). This would be more commonly used when a user knew of a specific artist but perhaps didn't know the precise spelling of the artist's stage name.
[0136] 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.
[0137] All search modes have three different ways of determining what genre of music the artist/song has been defined as belonging to:
[0138] 1. All genres, see Fig. 17;
[0139] 2. Only selected genres, where the user will check the desired genres, see
Fig. 18.
[0140] 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.
[0141] Note that the search current criterion is as shown in the figures, but the following modifications can be made.
[0142] In addition to looking up by country, users will also be able to look-up by regions. Additionally information will be able to be toggled in the results grid including: artist stats like total fans and site hits, artist songs stats like average ratings of songs, and links for the artist selected songs similar to those found in the music list module described hereafter.
[0143] 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. The genre wheel concept implemented assigns a number from 1-24 to each genre in the order that they appear on the wheel (e.g. pop=l, rock=2, etc.). When a user picks a genre to define themselves or one of their songs, that number is the value that is stored in the database. A search is performed using the genre wheel concept using the starting point direction and range. For example: 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
[0144] 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.
[0145] 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.
[0147] 2. Interviews and guest commentaries.
[0148] 3. Questions of the week.
[0149] The articles and interviews have links for current documents as the articles will be formatted on individual basis and since the page as a whole is representative of the general site look and feel no figure is included. In a general sense the layout of the page will be similar to the About page shown in Fig. 21. About Us Page
[0150] This will be a general information page giving the goals and mission statement of the assignee in general and MeAndMic specifically. Site Bulletin Board
[0151] A site bulletin board allows users to create postings as well as to review and answer these postings.
[0152] The postings themselves will be stored in the database and retrieved to a container such as gridview based on passed parameters to a stored procedure. For the most part the functionality is quite similar to the search page.
[0153] 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.
[0154] 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.
[0155] 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. [0156] The directories (categories) can include: musicians wanted, bands wanted, instruments for sale, general equipment for sale, general services wanted/provided and more.
These categories can change as the site progresses based on user need.
[0157] In much the same way as the search page the results will be presented in a paged gridview. Instead of links to the artist PWP, the entries will have links to other pages.
[0158] 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.
[0159] When creating a listing the user can leave external contact information like phone numbers or email addresses, but if they rather they can also toggle that the listings can only be replied using the MeAndMic message system. This would result in a link of on the listing that when clicked would navigate to a page where a response could be composed.
This page would incorporate a Telerik RadEditor similar to the blog module editor see Fig.
50.
[0160] The general look and feel of this page is quite similar to the search page, see
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.
User Data and File Management
[0161] All user data, file management and other customizations are accessible from the user settings page; see the prior description for more on how the user settings page fits into the entire site structure. All pages described in this section have checks that confirm that the logged in user (determined by the HTTPContext.User session object) matches the userid in the URL. If these two pieces do not match, the user is redirected to the front page.
[0162] The personal user folder will be described at this point. A folder named
"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:
[0163] 1. The style file,
[0164] 2. A subfolder titled "songs" containing all user song file,
[0165] 3. A subfolder titled "images" containing all user images, xml image lists and temporary images, and [0166] 4 A subfolder titled "resources" which typically contains the pagelnfo file any xml data files needed for module settings This folder may contain other data needed for future changes in the site.
User Data
[0167] Accurate user personal data is for the most part optional for free members with accurate name and contact information being required for paid accounts. User data is accessed from a page directly linked from the user settings page. The first page from this link has a summary of user account information and contains links to the individual pages for editing data in specific categories, see Fig. 22.
[0168] The mam account information page , Fig. 22, is shown as having three categoπes for example'
[0169] 1. 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.
[0170] 2 Primary profile information, which contains information about the account holder, which would be their real world name, address, and other contact information.
[0171] 3. Artist profile information, this would be the data about the user as an artist
This would be their stage name, artist type, members and genres. The bulk of this information is not required per sea but will enhance the artists ability to be found through the search page as well as will help to automatically populate data in other areas, for example like the about module and player listing
[0172] If the premise of paid membership is implemented, an additional category will be added to this page. Additional sections may be added as needed.
[0173] All data is stored in the database in tables that are related to the core user table by way of the user ID Where 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. In the case of one to many data (like the group members), 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.
[0174] As previously stated all pages under this section are transferred by way of the
HTTPS protocol to ensure secunty of information.
Image File Management [0175] 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.
[0176] The basic structure for image management as follows: 1) The actual image files are kept in sub folders of the image folder which can be found 2) As shown in the figures the image file management page is implemented using three views, the links to these views are at the top of the page and are:
[0177] First, a page to manage existing images, see Fig. 25. This page is implemented using a modified version of the image browser. The main change from the standard image browser is the addition of an area to view and edit the image logical name and descπption. Upon saving the control updates the image xml file for the given folder.
[0178] 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.
[0179] The folder tools allow the user to :
[0180] 1. Create new folders; there may be a cap of custom folders, such as 20, for example Users name the new folder using a custom dialog and cannot select from existing names or reserved name, as well as cannot use names with special characters in them.
[0181] 2. Delete folders although the folder in question must be empty first as well as the general and icons folder are impervious to deletion.
[0182] 3. Rename folders This function has the same restrictions as naming a new folder described above.
[0183] 4 In all cases existing images used in modules and other areas are not retargeted so users are notified to review their folders with missing image links after renaming folders.
[0184] The file tools allow the user to
[0185] 1. Move one or more files to another folder. Controls prevent the movement of files to the same folder. Additionally if a file of the same logical name is moved to another folder containing an image with the same logical name the newer image name is appended with a " 01", "_02" and so on. As images are given a pseudo random name when uploaded
(see next) it is virtually impossible for two images to have the same file name
[0186] 2. Delete one or more files. If images are deleted the user is forced to confirm deletion first and then notified to check for missing image links in their PWP [0187] The third view allows users to upload new images, see Figs 27 and 28. For example, there may be a 20Mb cap for free accounts; but this can change. The current image total is checked by way of the Directorylnfo object in ASP.NET. The following should be noted:
[0188] The upload process, see Fig. 28 utilizes the Telerik RadUploader as well as
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.
[0189] As with moving images, duplicate names are handled as described above.
[0190] When an image is uploaded the file name of the source file is kept to sixteen characters and a number based on the 'ticks' of the current server date and time is appended to that. This ensures that it is virtually impossible for a user to have two files with the same filename. In actual fact the users are never exposed to the filename and as such have no means to circumnavigate this protection.
[0191] Successfully uploaded images are confirmed with the user.
Song File Management
[0192] The song file management page, Fig. 29, 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.
[0193] 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:
[0194] The song title, which can be limited to 25 characters in length, for example.
[0195] The song genre selected from a combo-selection forcing compliance with the various site-searching functions.
[0196] The type, which can be cover, original or remix.
[0197] The author of the song. Note that by the user agreement users are required to correctly site cover songs and the original author of the song.
[0198] 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.
[0199] Additional information is maintained in this record but not available for direct editing by the users including the song status, upload date, deletion date, plays and aggregate rating.
[0200] If a song is deleted its status is changed from active to bin (short for recycle bin), see Fig. 30. Currently 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.
[0201 ] If a user wishes to change any of the accessible song data they can click on the edit link in the active song gridview, which will navigate to a form containing the data, filtered for that single song. This form is implemented using a display and edit modes similar to the previously described user data interfaces, Fig 31 and 32.
[0202] If the user has less than their maximum capacity of songs they can upload new song files either by using the upload a song link in the corner of the interface. This will lead to a two-step process shown in Figs. 33 and 34 where first they will enter the song data and then select and upload the track. The controls and interface for uploading a song are the same as for an image.
[0203] If a user is at maximum song capacity the upload link is disabled, see Fig. 30.
[0204] It should also be noted that if there is room in the song cap, new songs can be uploaded using the recording application. Although this application is not able to delete or change data on existing songs, it is capable of editing the songs effects and replacing the existing version with the edited version.
Message Management
[0205] 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.
Messages of all types are in the same table and their data would include:
[0206] 1. Unique message ID.
[0207] 2. The date created. [0208] 3, The date sent.
[0209] 4. A subject line.
[0210] 5. A HTML formatted message.
[0211] 6. The user id of the sender.
[0212] 7. The priority of the message.
[0213] 8. The status of the message, which would indicate if a message is to be displayed, deleted, shown in a module etc. Possibilities would depend on the message type.
[0214] 9. 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:
[0215] Notifications, which are messages from the admin staff, typically alert users to site changes and new features.
[0216] 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.
[0217] Fan submissions, which are initiated through an instance of a fan module.
These messages would initiate a request to be listed as a fan of a given artist.
[0218] 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.
[0219] 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.
[0220] 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.
[0221 ] If a message is deleted from the manager, the status (described above) is merely toggled. The message is not deleted immediately to allow for a user to restore a message in the case of error. Messages with a status of deleted would be removed from the system on a weekly basis using a automated stored procedure. Fan Management
[0222] Fans are similar to friends on other social networking site with the exception that they are not always reciprocal. In other words a user 'A' could request to be made a fan of another user 'B'. This does not necessarily mean that user 'B' would become a fan of user
'A'.
[0223] 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.
[0224] Fans are stored in the database utilizing a many to one relationship to the user table. Data stored in this table would include:
[0225] 1. An unique ID
[0226] 2. The fan id, which would be related to a user id on the user table.
[0227] 3. 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.
[0228] 4. The date applied by the initiating user.
[0229] 5. The status of the fan: applied, approved or rejected.
[0230] 6. A user defined category of the fan, which will facilitate organization on the fan-listing module.
[0231 ] 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.
Playlist Management
[0232] Playlists can be created from the site-wide player, and this page will allow users to manage these playlists as well as distribute them.
[0233] 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.
[0234] Generally playlist 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:
[0236] A list control on the left-hand side of the screen which will contain the available playlists.
[0237] Selecting a playlist will load its contents into a second control on the right-side of the screen which will in most respects be similar to the playlist grid shown for the site- wide player minus the controls to rate the track see Fig. 58. Users will be able to select records in this grid to enable the functionality next described. [0238] There will be additional controls at the top of the grid to:
[0239] 1. Move tracks up, down, to first and last position.
[0240] 2 Remove a track from the list.
[0241] 3. Randomize the list.
[0242] 4 Sort the list by any of the headings.
[0243] 5. Save and cancel buttons as well controls to copy a list or rename a list will also exist.
[0244] There will also be controls to send a list to other user's or even to an offsite email address. Sending to another user will be a free service but sending to an email will be a charged service unless the sending user is a paid member in which case a number of free submissions per month will be given as part of the membership.
[0245] In the event that a song is deleted by its owning user then the song id will be removed by a stored procedure for all playlists that contain that song. User Personal Web page
[0246] The personal web page (PWP) 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] When a user accesses a PWP, 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.
[0248] 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:
[0249] A 'my Pages' node for the pages collection which indicates next ID's for new modules and pages.
[0250] 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
[0251] The page name.
[0252] Whether it is public or private.
[0253] What number it is logically on the site.
[0254] Whether it is a single or two column layouts, Figs. 36 and 37.
[0255] Three child nodes to contain module nodes. One for the left column, the right column and the wide column.
[0256] Each column node contains zero or more module nodes. A module nodes has a number of values for the:
[0257] Module ID.
[0258] The module prefix which helps to determine how to handle module moves and deletions.
[0259] The module title.
[0260] The module visibility, i.e. whether it is public or private.
[0261] The set of the module control files to load for the PWP in public and private mode, the control needed to edit the module settings and if needed a deletion handler control.
[0262] 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.
[0263] As noted above 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
975px wide. For a two column setting left modules are 250px wide and right modules are
700px wide. Most modules are created for all three versions. Pn the event that a module is not conducent to a left version the module registration file prevents a module from every being moved to the left column. [0264] This system is implemented using XML, but can be switched to a database approach. This would be a transparent change to the user with all interfaces described going unchanged. The only major change is that node values would become fields and child nodes would be normalized to related tables.
Page Layout interface
[0265] 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.
[0266] As previously described the pages are defined in the user's individual pagelnfo xml file. The controls on this page layout page simply manipulate the xml file with the following notations:
[0267] A maximum of 10 pages can be added to a user site.
[0268] New pages are always given a unique name, placed last and are set to private visibility.
[0269] A page must be empty of modules to be deleted.
[0270] A page name must be 16 or fewer alphanumeric characters.
[0271] The first page is always considered to be the default page, i.e. the page that is loaded if someone accesses an incomplete URL.
[0272] The default page must always be public.
[0273] A user cannot delete such that no pages are left.
[0274] Otherwise the file is interacted with using a common XML interface. The controls are all AJAXified to prevent post-backs and as is standard this page uses the custom dialogs described above.
Module Layout Interface
[0275] The module layout, see Figs. 39 and 40, gives the tools for specifying what modules exist on the pages and where they are laid out. As with the page layout interface the controls on this page interact with the pagelnfo file for a given user. Again the controls are
AJAXified to prevent postbacks and to create a fluid environment.
[0276] Much of how the module interaction is accomplished is by way of a single file called modreg.xml. When a new module is made available to the site it is added to this file.
This file is checked whenever a module is added by a user, moved etc. to ensure that the proper controls are utilized.
[0277] The file starts with a moduleList node which then contains the individual module nodes. Each module node contains the following: [0278] Values to indicate the module prefix (i.e. short name) and common name.
[0279] Child nodes for each of the public and private files for each column configuration as well as the controls for editing the module settings as well as a deletion handler if need be. A child node to indicate whether the module can only be placed once or multiple times.
[0280] A child node to indicate whether the module can be placed in all three column types (1), right or wide only (2) or left only (3). A child node called 'modDesc' that contains other nodes called 'descPara'. Each of these description nodes would contain a paragraph of information that together would comprise the description and usage of the module. [0281] Finally a child node called 'defaultPara' that would contain one or more
'param' nodes. Each param node would have the default parameters for the module's settings. These can be changed later through the edit settings interface. [0282] 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.
[0283] It should be noted that if a module requires initialization of a data file or record in the database that this is handled by the module itself. When a module attempts to find a data file that does not exist it will instead load a control giving the user the option to initialize the file. If the user has already initialized the file and perhaps it is corrupted, then the user is requested to notify the admin to look into the matter and potentially recover the file.
[0284] Users can interact with existing modules either moving them up or down in the appropriate column listing in the pagelnfo file. Safeguards are utilized to ensure a module is not moved beyond first or last position. A user can change the layout of the current page from a single column, Fig. 39, to a two column layout, see Fig. 40 or vice-versa. When going from single to two, all modules default to the wide column. If the current page is in a two column layout modules can be moved from one column to the other assuming that the modReg.xml settings allow. [0285] 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.
[0286] Finally, 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).
Style Customization Interface
[0287] 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
Figs. 41, 42, and 43.
[0288] The system allows for the creation of two sets of module styles for example, as well as common background style. This may be expanded to more styles or even different page styles but the fundamental concepts described below will stay consistent.
[0289] Each user has several files in the root of their personal folder to facilitate the development of their styles:
[0290] 1. A text based ess file of their style sheet.
[0291] 2. A second text based version to serve as a backup in the case that they wish to reset their changes.
[0292] 3. A serialized version of each file. The site has a custom style sheet class which can be constructed ideally (for speed reasons) from the serialized file. If the file does not exist the text based file can be used.
[0293] When the PWP loads the code behind checks for the user's serialized style file, loads it into memory and writes it into a placeholder as an embedded style sheet. If the serialized version does not exist the text version is used in construction and serialized version is saved after the fact.
[0294] The same principle happens when the style customization page loads except that the backup file is updated. This way if the user opts to reset the styles before saving they can start all over again. When a user wishes to set their styles they have two options:
[0295] 1. They can pick from a list of preset style choices.
[0296] 2. They can customize their existing choices.
[0297] When a user customizes their styles they follow these steps: [0298] 1. First, they pick the element they wish to modify. The associated examples are shown in the preview to the right. E.g. they can pick 'normal text' or 'textbox edit mode'.
[0299] 2. Second, they would then select whether they want to modify the style one or two version.
[0300] 3. Third, they then could select from a series of controls the settings they want to apply. Typically these might consist of:
[0301 ] 1. Combo-selections for line types, thickness, font effects and font faces.
[0302] 2. 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.
[0303] 3. A link to be able to access an image browser to assign background images and list bullets.
[0304] Finally the user would select the 'Apply to preview' link to see their changes in the preview. They could at this point, continue to set other styles, reset their styles or save to see them on their PWP.
PWP Modules
[0305] As stated 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.
Edit Module Settings Interface
[0306] As shown in Figs. 44 and 45, 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.
[0307] The link that access the edit page passes by the URL:
[0308] 1. The module ID;
[0309] 2. The user ID; and
[0310] 3. The page number to return to .
[0311 ] 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.
[0312] Most of the settings that are not data specific would be saved in the pagelnfo data as parameters, see Fig. 44. The standard settings would be considered to be: [0313] 1. The title;
[0314] 2. The security mode; and
[0315] 3. The display style, additional parameters might include:
[0316] 1. Content heights;
[0317] 2. Page sizes for grids; and
[0318] 3. Default images, date formats, etc.
[0319] In some cases if there are additional data specific settings that are module- wide they will also be set in this interface see Fig. 45. Additional data would be set on a module specific basis either in the database or in an associated xml file (see individual modules for examples). About Module
[0320] 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. [0321] 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:
[0322] 1. The display image. This is selected using the image browser see Fig. 14.
[0323] 2. The display image height.
[0324] Additionally 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.
[0326] 2. The recording label.
[0327] 3. The user' s home address (typically just the city and province).
[0328] 4. A list of the members.
[0329] 5. A list of the genres.
[0330] 6. A description of the artist.
[0331] 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
[0332] 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.
As it stands 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.
[0333] 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:
[0334] 1. The height allocated for each entry.
[0335] 2. The sort order of the entries.
[0336] 3. The page size of the gridview.
[0337] 4 The date format of the entry.
[0338] 5. A default image for new entries. This is selected using the image browser shown in Fig. 14.
[0339] 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.
[0340] 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.
[0341] In private mode there are also links for:
[0342] 1. New entries, which link to the editor for a new message with the default image (if set) and default date as today.
[0343] 2. Edit each individual entry, as above except the editor will load the entry based on a passed by URL blog entry id. [0344] 3. Delete each individual entry, this will run a stored procedure to delete the entry from the database.
[0345] The editor, 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.
[0346] Page changes are handled using AJAX to prevent postbacks where possible.
Music List Module
[0347] 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.
[0348] 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 can also exist:
[0349] 1. The song sort order
[0350] 2. The page size of the gridview
[0351 ] 3. Whether to display the song image and if so what size
[0352] 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.
[0353] If the site just supports the single song player, the link to just "Play Track" exists. If a site-wide player with playlist is provided, users will have the option to either
"Add to playlist" or "Replace playlist".
Image Viewer Module (Slide Show")
[0354] 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:
[0356] 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.
For example, even though an image might be set for a height of 300px if that adjustment would result in the proportionate width exceeding the display area, the image would be sized by width.
[0357] Additionally 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:
[0358] 1. Move up or down an image in the list.
[0359] 2. Access edit mode for the data of the given image
[0360] 3. Remove the image from the list, this does not remove the image file from the personal folder.
[0361 ] The slide-show on the module is presented using a modified Telerik
RadRotator control bound to the xml file. Clicking on a image invokes client side scripts which change the displayed image.
[0362] In the case of the left version of the module, clicking on the thumbnail of the image forces a pop-up window with a version of the slide-show similar to the right module version shown in Fig. 56.
Feedback Module
[0363] The feedback module is in most respects laid out the same as the blog module.
[0364] 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.
[0365] 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:
[0366] 1. The height allocated for each entry. [0367] 2. Default sort order. Comments can be sorted by either or both date or priority. The priority is set by the artist in the message manager.
[0368] 3. The page size of the gridview.
[0369] 4. The date format of the entry.
[0370] As with the blog module 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.
[0371 ] In one aspect, 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.
Fan List Module
[0372] The fan list module provides a means for the artist to display on their PWP selected fan groups that they have created.
[0373] 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 can also exist:
[0374] 1. Show request link. This will display or hide a link on the module to make a request to become a fan.
[0375] 2. Default sort order, allowing the user to select how fans are displayed on the module. E.g. ascending by stage name, descending by request date, etc.
[0376] 3. The maximum number of members to show for each list. If more members exist than this number the list will be paged.
[0377] Additionally, from the edit link, the user will be able to manage the lists shown. 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 the image viewer module slide show. This interface will allow the following:
[0378] 1. The user can add any list defined from their fan management page.
[0379] 2. 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.
[0380] 3. The order of the list, if more than one is selected, on the module. [0381] Users can utilize multiple lists in a couple of ways. They could opt to only show one list in a given module and add multiple modules to their PWP, or they can choose to show more than one list in a module.
[0382] When the module is loaded it will check which fan lists to display, retrieve the data from the database and lay each list out in a gridview.
[0383] 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.
Playlist Module
[0384] The playlist module allows the user to display selected playlists that they have saved. 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:
[0385] 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.
[0386] 2. A display option as to whether to use a combo selection of playlists or to show the playlists one after another.
[0387] 3. The maximum number of songs to show for each list. If more songs exist than this number the list will be paged.
[0388] Additionally from the edit link the user will be able to manage the lists shown.
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.
This part of the interface will allow:
[0389] 1. The user to select which lists to display from any of their saved lists.
[0390] 2. A description for each list.
[0391] 3. The order o f how the lists are disp layed .
[0392] 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 [0393] 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.
[0394] 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 setting can also exist:
[0395] 1. There is a control to selected the background color/image or leave it to default to the one specified in the style selected.
[0396] 2. The user can define the content height or leave it as size to fit. In the case of the former a scrolling division will handle overflow.
[0397] From the edit settings page the user can access a page that contains an editor similar to the one for the blog module. There will be additional toolbar buttons to allow for hyper linking as well as image placement. As with the blog the information is rendered as
HTML but in this case the content will be saved in a data file specifically for each module instance.
[0398] From the edit interface, 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).
[0399] The module layout itself is essentially blank and other than the title bar serves as a container for the content created by the user.
Merchandise Module
[0400] 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.
Music Player
[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.
[0402] 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. Single Song Player
[0403] The single-song player, Fig. 57, is utilized on the site in places where a more streamlined control is appropriate, for example via a preview link for a given track. The player interface is divided into two sections:
[0404] 1. At the top is the player which is a GTE created Macromedia Flash CS movie.
[0405] 2. At the bottom is a series of controls to show the currently playing song data.
[0406] As stated 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:
[0407] 1. 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.
[0408] 2. 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.
[0409] 3. If the Flash player is ready the pop-up then hands off a play request to the movie along with the needed song information specifically the song path. As the track is loading a progress bar is displayer. In the default setting the song plays it once it has been completely loaded, however a toggle can be switched by the user to have the song buffer and play as it is coming in.
[0410] 4 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.
[0411 ] The player has display areas to indicate the current track, its play state, and time position.
[0412] The illustrated player skin is shown in Fig. 57 by example and may take other configurations.
Site Wide Player and Playlist Tool
[0413] The site- wide player shown in Fig. 58 can replace the single-song player in most circumstances. In addition to maintaining a playlist, the site-wide is sectioned as follows: [0414] 1. The top left-section has controls to show the data for the current track.
[0415] 2. The top-right section contains the flash player movie.
[0416] 3. The bottom contains a Telerik RadTabStrip control which has two tabs:
[0417] 4. The first contains a grid of the current playlist.
[0418] 5. The second accesses the search controls to find new tracks.
[0419] 6. 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.
[0420] The site wide player is, for the most part, the same as the single-song player with the following differences:
[0421 ] 1. There are also next and previous song buttons.
[0422] 2. The repeat button also has additional states for repeat all, and repeat current song and no repeat.
[0423] 3. 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.
[0424] 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. Although 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:
[0425] 1. Each artist name is linked to open the artist's PWP in a new window.
[0426] 2. There are controls to force the track to play next as well as controls to remove the song from the playlist.
[0427] 3. 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.
[0428] 4. As mentioned previously, when a song has played at least 75% a 'rate this track' control will be enabled next to the title. This link will remain active until the user rates the track unless the user has recently already rated the song. This would be checked by a cookie with duration of one week, for example. [0429] The search for tracks tab will access a series of controls similar to the one's described on the search page. The key differences are that they can only use these controls to search for songs, not artists, and the results list will have a link to add a given track to the playlist.
Recording and Effects Application
[0430] Users can upload standard mp3 tracks via the music manager but will also be given the opportunity to download and install a separate application Recording and Effects
Application (R&EApp), shown pictorially in Fig. 59, that will allow them to:
[0431] 1. Record new tracks using a straight line in recorder.
[0432] 2. Record new tracks using a karaoke style recorder.
[0433] 3. Add effects to existing tracks.
[0434] 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.
[0435] The key areas that the application will interface with the server include:
[0436] 1. Validating the user's ID and password. Only active users will be able to use the application as well as this will retrieve maximum song capacities for uploading purposes.
[0437] 2. Uploading new tracks (simple or karaoke based) to the user's personal folder as well as making the appropriate entry in the database.
[0438] 3, Uploading modified tracks to the user's personal folder, this would not generally affect the database entry for the track.
[0439] 4. Synchronizing the user's song list on the database with the application.
Including downloading tracks that exist on the server but not locally.
[0440] 5. Synchronizing the list of available karaoke tracks on the server. Note only the list is synched at start of opening the application, tracks are only downloaded on a needed basis. These tracks are kept locally in a cache that is not immediately accessible to the user.
If the cache reaches capacity it will remove the oldest files first.
[0441] 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. [0442] 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.
[0443] As described above, 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. At the point of recording 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.
[0444] 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. [0445] The third aspect of the application is the ability to edit local tracks and add effects. The options offered are:
[0446] 1. The ability to trim the beginning or end of a track.
[0447] 2. The ability to adjust the playback volume.
[0448] 3. The ability to make adjustments utilizing a ten band equalizer manually or selecting from a series of presets.
[0449] 4. The ability to apply reverb and echo effects, picking from a series of presets of each.
[0450] 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.
[0451] The following figure is an illustration of the recording application. It may have different placement or labeling of controls as well as the 'skin' applied to give a different overall look and feel. Venue Listing System
[0452] The venue listing system provides users with a means to look for venues in a specific region determine contact information and evaluate the venues. [0453] The system includes a series of table in the database, including a table of the venues and user ratings. [0454] The venue table contains the following information: [0455] 1. The name of the venue.
[0456] 2. Contact information including address, phone numbers, email and website.
[0457] 3. Boolean fields indicating whether the venue is active as well as whether it is on confidential status.
[0458] 4. Additional information such as the predominant genre, hours of operation etc.
[0459] The venue table also contains:
[0460] 1. A unique id, the date and a foreign key to relate to the venue table.
[0461 ] 2. The rating, the user who made the rating and the date of the rating.
[0462] 3. A comment field.
[0463] Currently 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.
[0464] There is a link for a user to access a form allowing them to submit a venue to the site operator. The venue would be added to the database with an unconfirmed status and an email sent to the admin account. The site operator will review these applications for accuracy before adding them to active status.
[0465] Users can search for venues in much the same way that they search for artists.
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
PWP's and will instead be directed to a page showing:
[0466] 1. The venue information.
[0467] 2. The aggregate rating of the venue.
[0468] 3. Selected user comments. These comments would be selected for appropriateness by GTE staff.
[0469] 4. Controls to rate the venue and leave a comment.
[0470] 5. A control to notify GTE staff regarding inaccurate information or a request to remove a venue from the list.
[0471 ] Venue accounts may also be provided to manage their own data in much the same way as the artists.
Merchandise Management System
[0472] 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. User Interface
[0473] 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).
Order interface
[0474] The order process will be a step-by-step process
[0475] 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.
[0476] Step 2: user selects a product and additional information including quantity, model, sizes, colors etc. Note: quantities can be restricted for first-time orders. Products and logistics may include some of the following for example:
[0477] a. Shirts - types (T-shirt, long sleeve etc.), colors, layout (logo on back or front position etc.) and print style (screen, iron-on)
[0478] b. Buttons - sizes
[0479] c. Stickers - sizes and layout, and
[0480] d. Posters - print sizes.
[0481 ] 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.
[0482] Step 4: user selects whether the product goes into their online stock or is shipped to them.
[0483] Step 5 : user information is entered; this can be retrieved from previous orders.
Users at this time can also set notifications and sales prices, although these can modified later.
[0484] Step 6: price is determined, for example, on
[0485] a. Product model;
[0486] b. Add features;
[0487] c. Artwork processing (free if they are repeating an order);
[0488] d. Quantity (there are price breaks based on qty);
[0489] e. Sales tax (where appropriate). [0490] Step 7: credit card is processed. We are currently investigating 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.
[0491 ] User will be notified by email when order is placed, and when product is either shipped or available for purchase on site.
Sales interface
[0492] 1. Pricing: the user can set price levels of the product as well as groupings or packages. Pricing minimums and maximums will be controlled by GTE.
[0493] 2. 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
[0494] 3. Notifications: users can set notifications based on product levels etc.
[0495] 4. 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.
Reporting tools
[0496] Sales History: allows the user to see sales with a number of criteria including;
[0497] 1. Sales by date range
[0498] 2. Sales by region
Customer Interface
[0499] The customer will see products for sale from the module on the user's page (as described above). Additionally there may be throughout the MeAndMic website to featured artists products. In all cases sales links will navigate to a discrete sale pages.
Product selection interface
[0500] The customer will select products using a shopping cart model. Products and artists can be navigated through the site pages:
Checkout interface
[0501 ] When the customer navigates to the checkout, a standard procedure would be followed:
[0502] Step 1 : review the current contents of the cart and adjust levels
[0503] 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.
[0504] Step 3: enter payment information, again can be retrieved securely
[0505] 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
[0506] The site operator interface allows the site operator to manage the supply chain from any location as well as monitor transactions and accounting.
Shipping/Receiving Interface
[0507] The shipping interface will help the shipping/receiving dept to manage tasks.
It would be accessible through a web interface.
[0508] Ordering: Reports 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.
[0509] 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.
[0510] Receiving: There should be a report to print outstanding orders or orders due
[0511] 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.
[0512] Shipping: as above when the order is shipped an email notification goes to the customer.
[0513] 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.
Accounting Interface
[0514] 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.
[0515] Order reports: A summary of orders placed and totals for reconciliation with manufacturers/printers billing is needed. [0516] Sales reports: Daily, weekly and monthly reports should be available to reconcile with Credit Card vendor reports as well as for bookkeeping purposes.
[0517] 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
[0518] Tax reports: Monthly reports showing taxes payable.
Merchandise Management- Artist Interface
[0519] 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. 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.
[0520] This part of the system can be thought of as having three parts:
[0521] 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.
[0522] Part 2 Inventory Management - this part 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.
[0523] Part 3 Reporting Tools - this part includes the reports accessible by the artist as well as GTE showing order histories as well and sales specifics for a given artist.
Artist Interface Part 1 - Ordering Products
[0524] This part describes the tools that the artist has to order products for sale.
[0525] Step 1 : select the products to order
[0526] Step 2: upload and place artwork
[0527] Step 3: confirm artist information
[0528] Step 4: checkout
[0529] Step 1 : select the products to order
[0530] The artist will follow a series of steps to select the product that they wish to order. Each step is clearly labeled and has the ability to move back to previous steps or cancel and return to the first step.
[0531] Sub-step Ia: Artists can select a given product from a catalog of products.
Products to be initially offered will include: shirts, buttons and stickers. [0532] Sub-step Ib: depending on the product there may be a next step where the artist picks from a sub-type. For example:
[0533] a. a button might come in more than one size,
[0534] b. a sticker might come in different dimensions, and
[0535] c. a shirt might be long-sleeve or t-shirt.
[0536] 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.
[0537] 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.
Cart Notes
[0538] At this point the items would be in the cart and the user would be directed to move on to Step 2. There should be the consideration that an artist might not have artwork ready when presented with Step 2, so 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.
[0539] Step 2: upload and place artwork
[0540] 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.
[0541] Sub-step 2a: the artist can select from previously approved artwork. This would bump them to sub-step 2d.
[0542] 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.
[0543] Sub-step 2c: the artist would upload the artwork from their computer.
[0544] 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.
[0545] There are a number of ways to do the preview. One example is to create a template control that processes the image as a parameter and then use DHTML to place the image over the product. This way the site operator could modify the template as new products are added.
[0546] 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.
[0547] Step 3: confirm artist information
[0548] As artists will have to be members to be able to access this feature and they should have complete information in their corresponding tblUser table (see Customer spec
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.
[0549] Step 4: checkout
[0550] The check process will also be similar to Customer spec Part 3 with the following notes:
[0551 ] The artists will have the ability to select whether the product will be sold by the site operator whether the product will be shipped to the artist so that they can sell it themselves
[0552] The cost will be based on a number of factors:
[0553] The quantity and type of product. The site operator manages this feature to add new products and change pricing. For example 50 stickers might be $X.xx and 100 stickers might $X.xx.
[0554] If the artist selected to have the product sent to them, there can be an additional handling fee and any applicable taxes.
[0555] Currently pricing can be shown in CDN and USD. Pricing will be determined based on one primary currency, but approximates can be calculated based on recent currency exchange rates.
[0556] Again the user will be notified upon completion, however there will be a notification regarding pending artwork confirmation; and there may be another confirmation after this approval.
[0557] For some artwork there may be additional handling costs. If the human review determines this, the amount can be added.
[0558] There is a possibility that the artwork may be unusable or that the given product unavailable. Again the artist will get notification. [0559] There will be a notification when the product is available for sale on their
PWP, or at this time the product may automatically become available if the artist has set-up pricing.
Artist Interface Part 2 Inventory Management
[0560] This part covers the tools offered to the artist to:
[0561 ] Section 1 : Set pricing
[0562] Section 2: Monitor sales
[0563] Section 3: Handle inventory
Section 1 : Set pricing
[0564] Before a product will be shown in the catalog or be able to be ordered:
[0565] 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.
[0566] The user can pick a price in this range based on the primary currency, and the approximate equivalent currently amount will be shown.
[0567] Prices can be changed but indiscriminant changes can be controlled. Possibly prices can only be changed once per week for a given product. There will be a notification that pending sales might be based on the previous sales price.
[0568] Product Information: the artist can add a custom description of the product.
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.
[0569] Packages: the artist can setup a package of products for one price. E.g. one shirt + 2 buttons.
[0570] 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.
[0571] Section 2 : Monitor sales
[0572] The user can review sales by volume and by product.
[0573] For products within the current month, there is a day to day breakdown; but previous months should be consolidated into one record with the breakdown stored in an archive Db (Users can be sent a report of this data for a fee).
[0574] This should also show to the user the pending revenues owed to them by the site operator.
[0575] Section 3: Handle inventory [0576] The handling of inventory would cover the following features :
[0577] 1. Automatic artist notification when a product falls to a determine quantity, based on the product quantity set by the site operator by default, but editable by the artist.
For example, 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.
[0578] 2. The ability to set automatic reorder levels for some products, this may be too complex for the initial deployment but should be considered.
[0579] 3. This would also be the interface where the user could "buy out" all or portions of inventory to be shipped to them for their own uses. This would be done accompanied by a handling fee.
Artist Interface Part 3 Reporting Tools
User Reports
[0580] The sales reports are described in Part 2 section 2 above.
[0581] 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
[0582] 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.
[0583] A report showing monthly sales revenue (total and less site operator fee) vs. payments sent by site operator. Total owed will also be shown.
Site Operator
[0584] All user reports are available to the site operator, but filterable for specific artists, regions etc. A report showing outstanding payments owed; and other reports can be provided.
Merchandise Manage - Customer Interface
Customer Interface Overview
[0585] This is a specification of part one of three of the Merchandise Management
System as a whole. 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.
[0586] This part of the system can be thought of as four parts: [0587] 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.
[0588] 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. [0589] 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.
[0590] Part 4 Follow-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.
Customer Interface Part 1 - Picking Products
[0591] During the Add process, the customer can navigate from a number of different pages, and when they view products they can add them to a shopping cart system. From the nav-bar a link will exist that will allow the user to view this cart which will give the customer the ability to adjust quantities or remove items (see Part 2). Customer Interface Module
[0592] Artists who have products for sale can opt to add and configure one or more merchandise modules to their Personal Web Page (PWP). The PWP is managed from the user/pagelayout.aspx and user/modlayout.aspx files. These files manipulate the XML file user/[username]/resources/pagelnfo.xml, which describes the structure and order of the user's PWP. Parameters for a given module can be stored in pagelnfo.xml but should generally pertain to the layout of the module and not it's content.
[0593] When a logged in user is viewing their PWP, they have access to edit links on each of the modules. This link navigates to /user/editmodule.aspx. When this page loads it refers to the moduleID and loads the control specific to editing that module. This control would be the way that artists could pick which products to show in the module, the order, and any short description. Prices etc., would be set in the Artist Purchase interface which will described in another document.
[0594] 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.
Customer Interface Merch Page
[0595] 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:
[0596] a. Featured or popular artist products,
[0597] b. A current shopping cart summary;
[0598] c. Searches/Filters by: artist information, i.e. artist name, artist genre, region
& country; and
[0599] 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.
[0600] If a product is out of stock, there is a link to notify the artist that someone is interested in purchasing that product. This notification can be shown in the Artist Purchase interface. If the customer is a logged in user, they can click a link on an out of stock product to be notified when that product is re-ordered. The results of the current search/filter can be paged
[0601] The results can also be sortable.
Data Storage
[0602] Membership database: The current MeAndMic system uses the standard
ASP.Net membership handler. The following tables and fields should be noted:
[0603] aspnet_Users: A table created as a part of the standard membership handler,
[0604] UserID : uniqueindentifϊer - the primary key of this table and the field used as the foreign key on all related tables,
[0605] 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,
[0606] aspnetJVIembership: A table created as a part of the standard membership handler,
[0607] UserID: uniqueindentifϊer - the foreign key relating to aspnet_Users,
[0608] Email: nvarchar(256) - the stored email of the user,
[0609] LoweredEmail: nvarchar(256) - a lowercase version of the above, [0610] 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,
[0611 ] fldPrimeTitle: char(4) - User title Mr., Mrs. Etc.,
[0612] fldPrimeFirst: varchar(50) - User First name,
[0613] fldPrimeLast: varchar(50) - User last name,
[0614] fldAddressl : varchar(l 28) - First of two address lines,
[0615] fldAddress2: varchar(128) - Second of two address lines,
[0616] fldCity: varchar(50) - User City,
[0617] fldRegion: varchar(50) - User region, state, province etc,
[0618] fldCountry: varchar(50) - User Country,
[0619] fldCode: char(lθ) - User postal, zip code,
[0620] fldPhone: char(l 5) - User phone number,
[0621 ] fldFax: char(l 5) - User fax number, and
[0622] 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"
[0623] 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.
[0624] Product Data: the product data should be stored in the database. The table containing product counts and transactions would presumably link to aspnet_Users.
[0625] Shopping Cart: the shopping cart can be stored in the database to facilitate users adding products closing the session and then returning at a later time.
Customer Interface Part 2- Reviewing Products
[0626] At any time the customer is able to review their cart to see the items added to it. The following features should be noted:
[0627] A given product can have links both to the artist PWP and to the Customer
Interface Merch Page (filtered to that artist).
[0628] Quantities are adjustable.
[0629] 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.
[0630] There is a possibility that, between the time that a product is added to the cart and the time that the cart is reviewed, a product may become out of stock.
Customer Interface Part 3 - Checkout [0631 ] The checkout is a standard system of confirming the products, adding/confirming customer information and connecting with the pay portal.
[0632] 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
[0633] 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.
[0634] 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.
[0635] Step 4: Connect to the pay portal
[0636] Step 5: Display printable receipt as well as email confirmation.
Customer Interface Part 4-Follow up and Reporting
Customer Follow-up
[0637] Customers will be able to access an order history page which will show:
[0638] 1. Completed orders they have made to date;
[0639] 2. Orders that are pending confirmation and/or shipping; or
[0640] 3. Out of stock notifications they have requested and the abilty to cancel these notifications.
Site Operator Reporting
[0641] 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.
Merchandise Management- Site Operator Interface
[0642] 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
"artist" is used it is referring to users who are selling those products.
[0643] 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.
[0645] Part 2 Shipping Management - this part will cover the tools that help the site operator to process customer orders.
[0646] Part 3 Inventory Management - this part will cover the tools used by the warehouse staff to check inventory levels and make adjustments where needed.
[0647] 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.
GTE Interface Part 1 - Ordering Products
[0648] As stated this part describes the tools that help GTE to obtain the products for sale accurately and efficiently. The ordering process can be thought of as steps
[0649] Step 1 : receive order notification
[0650] Step 2: approval process
[0651 ] Step 3 : place the order
[0652] Step 4: receive the product
[0653] Step 5: notify the artist
[0654] Step 1 : receive order notification
[0655] Order notification should come automatically to the site operator employee tasked with handling orders (an email account can be setup for this purpose).
[0656] The order should include:
[0657] 1. Reorder or new order if it is a reorder and funds have been confirmed then the processor can proceed to step 3;
[0658] 2. The artwork for review in step 2; and
[0659] 3. The order itself as well as dates and artist information (keep in mind that the person handling the order may not have direct contact information by other means).
[0660] Step 2: approval process
[0661 ] The approval process should include:
[0662] 1. Reviewing the artwork for usability, and
[0663] 2. Reviewing the order vs. any checks that need to be made with the vendor
(e.g. shirt type availability etc.)
[0664] 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.
[0666] Depending on the vendor, there may be a reply or follow-up needed for confirmation. To facilitate this, there the order form has the space to record this information.
[0667] Step 4: receive the product
[0668] 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.
[0669] Items like date received should default to the current day but be editable.
[0670] The products are moved to the storage space, which will be organized by
Artist -> Product Type -> Product Variation.
[0671 ] Step 5 : notify the artist
[0672] Once products are verified in the system they should automatically be available for sale on the site (assuming that the user has set prices). An email should also automatically goto the user notifying them that the product has been received.
[0673] Site operator Interface Part 2 Shipping Management
[0674] This part describes the tools that help the site operator to ship the products that have been purchased by users from the site.
[0675] Step 1 : print pending sales
[0676] Step 2: pick and package sales
Step 1 : Print Pending Sales
[0677] At any given point in time, 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.
[0678] 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
[0679] With the list of orders the shipper can pick the products, which should be organized by Artist -> Product Type -> Product Variation.
[0680] Once the shipper has completed the pick process, he can package the products and ready them for shipping. Later he can update the system using the interface, again the current date should be the default but still be editable and there should be a quick one-click method to indicate the order was shipped complete or alternatively indicate which items were sent.
[0681 ] Ideally all items should be available as it should not show on the website until it is received. However if an order is incomplete, the missing items can be left as backordered or the order as a whole can be set as 'partially picked' if the missing product is expected in a short period of time.
GTE Interface Part 3 Inventory Management
[0682] 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.
[0683] 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.
[0684] After the physical count, the staff member can make adjustments to the system by calling up the product in question and manually entering the count.
[0685] Note: adjusting entries of this sort should be recorded in the system so the company can account for lost items. The user id of the person who made the adjustment should also be recorded.
GTE Interface Part 4 Accounting and Reporting
[0686] 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.
[0687] A/P tools:
[0688] The following are provided:
[0689] a. A report of orders made either itemized or summary of totals (all, not received, received). This can be sortable/fϊlterable by artist and/or date range.
[0690] b. Amounts owed to specific vendors/printers. There is functionality to update the system when these amounts are paid.
[0691] A/R tools
[0692] A report of sales made either itemized or summary of totals (all, not received, received). This is sortable/filterable by artist, customer and/or date range. [0693] Amounts owed to specific artists. There is functionality to update the system when these amounts are paid.
Other Liability Tools
[0694] A report of all taxes payable to various authorities is generated. There needs to be functionality to update the system when these amounts are paid.

Claims

What is claimed is:
1. A method for an artist to create a customized webpage featuring works of the artist, the method comprising the steps of: providing webpage authoring software; providing access to the web software through a computer network; and in response to an artist request for one of creating and editing an artist webpage, providing one of selection and editing of a webpage layout, modules within the webpage, webpage style selections and artist information.
2. The method of claim 1 further comprising the step of: providing an image viewer containing artist related video information.
3. The method of claim 1 further comprising the step of: providing a listing of artist fan information on the artist webpage.
4. The method of claim 1 further comprising 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 webpage.
5. The method of claim 1 further comprising the step of: allowing the artist to record music directly on the artist webpage.
6. The method of claim 1 further comprising the step of: providing the artist webpage with a private portion accessible only by the artist and a public portion accessible by the public.
7. The method of claim 6 further comprising the step of: providing non -artist user access to the artist webpage public portion.
8. The method of claim 7 further comprising the step of: allowing non-artist user who accesses the artist webpage to search a list of artist works stored on the artist webpage public portion.
9. The method of claim 1 further comprising 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 all of the artist works assigned to one genre selected by the non-artist user.
10. The method of claim 9 further comprising the steps of: providing the plurality of selectable work genres in a continuous list; and providing the non-artist 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 non-artist user upon user selection of one genre.
11. The method of claim 1 further comprising the step of: providing merchandise for sale to a user who accesses the webpage of the artist.
12. The method of claim 1 further comprising the step of: providing a merchandise module accessible through the web server containing merchandise from a plurality of artists.
13. The method of claim 1 wherein the step of providing webpage authoring software further comprises the steps of: providing the artist with a selection from a plurality of modules including at least one of a music management module, a blog module, an image module, a calendar module, a fan management module, a bulletin board, classified monitoring, artist biography, and lyrics.
14. The method of claim 1 wherein the step of providing a webpage authoring software further comprises the steps of: providing an outlet via the webpage of the author's works which are output in a playlist.
15. The method of claim 15 further comprising the step of: providing the web server with a audio/video player to output artist works based on webpage viewer preferences.
16. The method of claim 1 wherein the step of providing webpage author and software further comprises the step of: providing the author with at least one of work editing tools, video and audio files, virtual busking, schedule of online concerts, and coordination of jam sessions.
17. The method of claim 1 wherein the step of providing webpage authoring software further comprises the step of: providing the artist webpage with an interactive ability to buy and sell artist related equipment, merchandise and exchange of artist related topics.
PCT/CA2008/002297 2007-12-27 2008-12-29 Website development and website usage for artists Ceased WO2009082821A1 (en)

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 (en) 2009-07-09

Family

ID=40823731

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2008/002297 Ceased WO2009082821A1 (en) 2007-12-27 2008-12-29 Website development and website usage for artists

Country Status (1)

Country Link
WO (1) WO2009082821A1 (en)

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 (en) * 2020-07-10 2022-01-13 Hewlett-Packard Development Company, L.P. Application version switching

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 (en) * 2005-08-17 2007-02-22 Wideport.Com Inc. Automatic website generator
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 (en) * 2005-08-17 2007-02-22 Wideport.Com Inc. Automatic website generator
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 (en) * 2020-07-10 2022-01-13 Hewlett-Packard Development Company, L.P. Application version switching

Similar Documents

Publication Publication Date Title
US10915946B2 (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
US7895082B2 (en) Method and system for scheduling transaction listings at a network-based transaction facility
US8131647B2 (en) Method and system for providing annotations of a digital work
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
US20050278644A1 (en) Method of acquiring products from vendor websites
US20030229554A1 (en) Method and system for composing transaction listing descriptions for use in a network-based transaction facility
WO2003104931A2 (en) Method and system for scheduling transaction listings at a network-based transaction facility
WO2009082821A1 (en) Website development and website usage for artists
US8234174B1 (en) Method and apparatus for creating custom advertisements
US20080027821A1 (en) Method and Apparatus for Promotion and Distribution of Electronically Stored Information
JP2001331737A (en) Network system and login method
WO2005045607A2 (en) Integrated marketing portal for businesses
Bondari Wordpress 2.9 e-commerce: build a proficient online store to sell products and services
Bangboonrit Site builder: build, market and manage business website with CMS
Jones Getting Started with Drupal Commerce

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