This is a repost for another project. We went back and decided to restructure the app. This is how we wish to proceed now. We are not picky on what tools that you use, but it must be cross platform and fit the other requirements.
Stand Alone Application (Web Automation Software)
Overview Of Project and Specifics
We wish to create a standalone application that will perform specific automation, and a web site that will serve as a base for our clients to purchase the software, or download a trial version. The software will require the user to input login credentials for various sites, which will be stored on our web-server. The software securely obtain (from our server), and then will use these credentials to log into all of the sites that are subscribed to by the user. The software will also retrieve specific pieces of information from the sites visited and store them in a database on the web-server. A scheduler component will allow the user to choose how often the sites should be logged into, and will use the system time as a guide. The software will eliminate tedious tasks for our clients, and thus create peace of mind by automating processes for them. We would like to track specific changes over time based on the information we gather in the server database, and then have the ability to display this information in the software, and to the user when logging into the site. The site itself will have billing functions, and many other standard functions. The entire site must be SSL Compliant. The software will need copyright protection, and be able to activate using keys emailed from the web server. Also, the software must be check for web updates, and update the software automatically when there are fixes, or when new versions come out. All communications between the stand-alone portion and the server MUST be SSL compliant. Also we need to be able to change pricing, and subscription classifications at any time. The software should be written in a cross platform fashion so that it can be compiled for vista/xp, mac osx, and linux. The software will need to have bug reporting so if there are errors related to changes in the design of the subscription sites, we need to be notified right away. We would prefer an ongoing relationship with the coder for future mods or fixes.
Stand Alone Software Components
Note: When the software is opened, and if the user has never logged in since installing the software, the user will be prompted for a username and password. This is the username and password for our site. Every time the software starts, it will log into our site and check their membership status and subscriptions, and tell the software to behave accordingly. Also it will update any other information between server and client, such as changes to alert preferences.
If the username and passwords fail, the software will prompt the user for their username and password.
Options: This section will have several options for the user to configure.
Option 1: Log in username and password (for our site)
Option 2: Open at system startup (yes / no)
Option 3: Check for updates at startup (yes / no) Recommended
Option 4: Run in background (keeps browser minimized while updating sites)
Run Now: This should allow the software to update any sites that you choose immediately. Only subscribed to sites will be available. A warning message will let the user know that certain sites may not be immediately accessible if they have been accessed within 24 hours.
Scheduler: The app will need to be able to synch with either your choice of system time, or an internet time server. The user will be able to schedule how often the software should log into and update the various sites. One of the sites can be updated up to 4 times a day, so for this site the user will be able to select 4 up to times a day, and configure those times. Or, you should be able to select if you want it checked every x days, and what time of day.
Other sites may only be done once a day, but are not restricted as to what time (reset at 12:01am). For these sites, you should have the choice of every x days, and what time of day.
Still, other sites can only be updated once a day, and will track the time of day of the last update. For these sites, the options will be check every x days. If the user selected every day, then the software will have the user select a time, and then after successfully updating each day, the scheduled time should be incremented by 2 minutes. If the user chose every 2 days or more, then no such incrementing should be done, and the same time will hold.
Stat Viewer: This should essentially mirror the similar part on the web-server updating and retrieving the same information from the database on the web-server.
Alert Manager: This should allow the user to configure all of the alerts that they want the site to send out. After the software alerts are configured, a message will be sent to our server telling it to send the specified message to the specified place.
Log: This should track when sites were logged into and updated, and also if there were any failures. An image of the failure should be accessible locally to determine the type of failure. Failures should be list able, and the image accessible when the specific failure is clicked on.
Help: This section should explain all of the software’s components. (we will write)
About: This section should state the software version, our website url, and and email contact for us.
A pop-up window should display upon start up for software that has expired asking for the username and password, and show them a hyperlink to our site where they may register. If they cannot login, or click cancel, the software will exit.
Web Site Components
(These are just elements, and the text and aesthetics will be done by an outside company, you will do any database, CGI, or coding on the server only.)
Home: This will be the basic front end of the site. It will have some text, and it should contain a frame for existing users to login with their credentials, and feature a menu bar containing (about us, contact us, sign up, pricing, and FAQ)
About (software title): This page will describe what the software does.
Contact Us: This page will contain information about how to contact us, and if logged in, allow them to submit a secure message.
Try It: This page should allow the user to download the latest trial version of the software.
Buy It: This page should allow the user to purchase a license for the software and also download it.
FAQ: This page will answer most questions that people may have about our services.
Log In Prompt: This should be a frame on the homepage that will allow existing users to sign in. It should have the ability to ask secret questions if you forgot your password, and email you a new password with a link asking you to change it at login.)
Google / Affiliate Ads: These ads should be tastefully placed somewhere on our homepage. We may also want certain ads displayed based on B.
EULA: This will be another document that users will see and must agree to before signing up
Viewable After Logging In
My stats: This page will present data collected from the services that is being stored on the web server in a database. The data should be viewable per service, and per data type, and should be able to create a graph with points for each data for data type B, and just a list for data type A.
My Account: This page will allow the users to see and modify any personal information they have given, including their email address, and also modify their login, secret question, password, or billing information, and also the ability to cancel the service.
My Subscriptions: This area will allow the user to select which services they wish to use, and the username and passwords and other credentials needed for each service. The billing arrangements will change based upon adding additional services. The user must be charged before additional services take effect.
The site must be able to handle data dynamically between the app and the server. This includes all of the data mentioned in the document.
The software should have code that will cause the program to crash if our server cannot be contacted, or provides an invalid response. This way, if the software is reverse engineered not to talk to our server, or to bypass our subscription service, the software will crash.
• Software must be able to detect errors in logging into the subscribing sites and then send a message to our server with the errors. A log file should be created, and this should be viewable to us. In addition, and email should be sent to us to alert us of the error.
• Any other miscellaneous errors that are easy to detect should be detected and documented.
• Alert to email when the software cannot successfully log in to an account due to wrong Username and Password. (NOT DISPLAYED AS A CONFIGURABLE OPTION)
User Configurable Alert in stand-alone software
• Alert to email on file when any specific request fails (pulls will be tried up to x(user configurable 1-10) times by software). The email should be generic, and also inform the user to check the software app portion.
• A screen capture should be done anytime there is a failure, and store this on the server. The app should create a log of failures, and save and display this to the user when they click on the failure.
• Email (specify email)
• Txt message (specify service and phone #)
• Alert when a new A appears.
• Alert when an A no longer exists.
• Alert with a total of A for each specific entity showing the first date and last date, AND how many A’s in the past X months (user variable). (Do only when there is a change)
For all events, always inform of the date, entity 1, entity 2, of each A that appears or disappears. Also, show a running tally of how many A’s are accrued through each entity. This should be on the portal site, and on each email. On the site the user should be able to view a log history of all events (new A’s, and A’s disappearing)
• Alert when a B changes.
• Alert when a B changes more than x value (user variable) (For Each entity)
Database (on Web Server)
A database should track A’s that are picked off of individual sites for each user. There should be data stored on all of the following:
• Site data from
• Date of A
• Entity 2
The standalone app will log in using the users credentials in order to gain access to the database to both update and view data. The standalone app should be able to view the data just like on the website.
Also, the database should track B’s from the sites. The data should be the following:
• Site Data From
• Value Of B
The database should be expandable for the future to allow for other data types that we may implement later. If not, there should be a framework to allow for multiple databases. The data is tracked so that we know the date and source of all A’s, and also totals from each entity per user. We need to know when an A appears, but also when it is no longer visible. We also need to know what Entity generated the A.
The database MUST be be secured in some way so that there is no unauthorized access possible. Customer information must not be compromised.
There should also be any additional databases needed for any other components mentioned herein.
Billing and E-Commerce:
We will need to be able to process payments from our clients for the services. The billing system must be able to handle all of the following:
• Process credit cards and maybe ach later on.
• Be dynamic to change billing arrangements based upon new subscriptions that the client selects.
• Accommodate activation fees.
• Be able to handle trial periods in which the client will supply their credit card at sign up, and not be billed until a certain point. The card data will be kept on file to prevent multiple sign ups.
• Be able to accommodate coupon codes.
• Tell the site to shut off access to accounts when payment is not received.
• Enable free accounts for beta testing
Billing Fields Needed For Client at Sign Up
• First / Last Name
• Billing Address
• Billing Zip
• Desired Username and Password (require 8+ char and letters and numbers)
• Email Address
• Security Question and answer (Favorite food, Pets name, etc)
• Credit Card #, CVV2, Expiration, Name on Card
The standalone app should direct the user to our website to sign up if they don’t have a username or password, or if their billing information is invalid.
The website should also send out emails letting the user know if there is a change to account status, or if there are billing issues.
We need to interoperate (log in) to 5 other sites, and possibly more in the future.
The stand alone software portion that logs into the specific sites that we handle must be able to automate logging in with username and passwords as well as other credentials, as well as clicking on links. The software must be changeable in case the sites change their URL’s or structure in any way. We also need a measure to detect these subtle changes so that we can be contacted if these to be fixed. In fact we may wish to have an ongoing relationship with the coder to fix issues every so often. We will need it done quickly if so. The software must keep track in a database (on the web server), all of the times and dates that it has successfully logged in, or began the extraction of data. (time URL is pulled of expected page showing new data). Logins made the following day must always be made 24 hours + 2 minutes from the previous time of day. This way they will defeat 24 hour time limitations on the sites and allow for pulls every day, while wasting the least amount of time.