PROPS GOALS AND PROPOSED FEATURES
NOTE: This document was drafted in 2001, when PROPS was in the planning stages. We've met some goals, missed others, and rethought still other goals as the software progressed. This document is left online for historical and educational purposes.
Part 1 - General design goals
- Simplicity == elegance. Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (more)
- We will enforce a Zero Tolerance policy with regards to bugs.
- All code will be commented liberally and clearly
- Code will be written according to PEAR coding standards
- While the initial release will support only text and image content, the design should be flexible enough to accomodate audio/video content in the future.
- PROPS is a publishing system designed specifically for periodical publications (primarily newspapers, but also magazines and web-only publications). It's not (and most likely never will be) a general purpose platform for web applications, a weblog, a groupware package, or a one-size-fits-all Content Management System. We will remain focused on the publishing market.
Part 2 - System administrator friendly
- PROPS should be very easy to install, with as little dependence on external libraries and applications as possible. Easy to install means lots of users, which means lots of potential contributors.
- Some PROPS features may require modifications to the Apache configuration file, recompilation of Apache, or root access to the machine. While we'll do our best to accomodate users of virtual hosting services, we offer no assurances that you'll be able to install or run PROPS without root privileges.
Part 3 - Modular design
- PROPS will feature a well-documented plug-in API to encourage development of third party add-ons.
- A 'plug-in exchange' download area will be operated to encourage PROPS users to share plug-ins.
- The plug-in API should allow new template tags, admin screens, and possibly database tables to be added.
- Plug-in installation should involve more or less just unpacking a tarball into the plug-ins directory.
Part 4 - From the reader's perspective
- Readers will be able to access content in HTML or WAP/WML format. Use of XML/XSLT will allow delivery in other formats as standards develop. (Note: we're currently not using XSLT, but it should not be hard to adapt the software to use it in the future if any benefits to doing so become obvious)
- Readers will be able to view a printable version of all stories, or email a story to a friend. XSLT will also be used to generate these versions.
- Readers will be able to perform advanced keyword searches on archives. Archives will be free, however if someone wants to add paid archives capabilities, we'll let you.
- All pages will be presented as static URLs, so that 'spider' type search engines may crawl and index stories. This should be a configuration option, since access to the Apache config file is required to enable this.
Part 5 - From the site designer's perspective
- A strict separation of design and content will be maintained. It should be easy for graphic designers to produce site-wide and single-use templates. Templates will be tag-based, and may be created using standard tools like Dreamweaver, GoLive, or BBEdit.
- Designer should have some control over the way photos are processed and presented.
Part 6 - From the editor's perspective
- The content management screens will have an intuitive and consistent end user interface. Style guidelines will be written to ensure that 3rd-party plug-ins are consistent with the core system's user interface.
- Multiple users will be supported through ACLs or user/group privileges.
- Editors will have access to a 'web desk' screen listing new stories from external feeds, and stories that have been assigned to them by another editor.
- In addition to editing stories from the wire, editors will be able to enter stories into the database using web-based forms.
- Stories may be scheduled to publish on a future date.
- Photos will flow into the web desk from external feeds/interfaces, and may be assigned to stories.
Part 7 - Advanced syndication capabilities
- PROPS will support the News Industry Text Format
- PROPS will speak XML for both import and export, allowing syndication in both directions, and enabling PROPS sites to participate in news networks.
- Initially, PROPS will support the popular Netscape RSS standard for syndication of headlines to other sites.
Part 8 - Performance, scalability and portability
- PROPS is targeted at mid-sized publishers serving fewer than one million page views daily.
- It should be possible to scale PROPS pretty linearly to increase capacity, by deploying additional front-end web servers behind a traffic director, separate image servers, etc.
- During development we'll evaluate different ways to accelerate PROPS, including dynamic generation of static HTML, and use of the Zend or APC accelerators for PHP.
- PROPS is being developed under MySQL, but database calls will be abstracted so we can add support for additional databases in the future (PostgreSQL and Oracle come to mind)
- Reference platform for development is Linux 2.4 with Apache 1.3.x, MySQL 3.23 and PHP 4.05. PHP3 will not be supported. We intend to make sure PROPS will run on other Unix platforms. NT/W2K/IIS support is dependent on whether we get requests for that, and more importantly, patches and development help.