For the OldCoder wiki index click here
Click here for the main OldCoder website


This page is presently intended for the following people: OldCoder, ziyadb, and SM staff. It provides preliminary notes on projects and issues related to SM. SM staff are able to edit the page and are invited to add remarks. For instructions, see OldCoder in IRC.

I'd recommend that clients not be provided with the link. If there is an interest in sharing material with clients, separate pages will be created for them on request.

The page structure may evolve rapidly if things get moving.

hotel2nite overview

SM says: Client is interested in a site that will allow him to upload hotel or spa information for customers who wish to book occupancy the same night. He will be involved initially with 110 hotels or spas in Scotland. 10 hotels in 10 cities or towns and 10 spa-type resorts. Each of these places will provide a number of rooms that haven't been sold yet to him at a greatly reduced rate. He will sell them for that single night only. He plans to target businessmen and people who are traveling on an unexpected or spontaneous basis. SM has been asked to devise a solution for this. This means costing a coded element.

The concept is similar to that used by an American firm whose site is located at:

SM adds: We'd need to make a site for a client who will offer hotel rooms for a night on the day before. He has 110 hotels or spas. Each hotel will give him rooms at a vastly reduced rate. He will offer these on the site but only for one night. These are to be inputted the day before to go live at midnight and replaced the following day. He will charge for each room booked and pay the hotel, minus his cut. He will initially input the data himself. but hopes to allow his hotels to eventually do this themselves each day.

OldCoder says: Two basic models might be used for development. These are discussed in the following sections:

  • Starting with a FOSS system and modifying it to match the client's needs
  • Development based on standard frameworks

OldCoder adds: The client wants a ballpark figure. As usual for large projects I'll recommend a modified Agile approach. There will be multiple steps and each will have deliverables. The first step will deliver prototype pages. After a review of the results, a quote or an estimate for a second step will be provided.

hotel2nite — FOSS approach

The FOSS approach to project development sometimes reduces costs significantly. However, in this case, this approach is presently a long-shot. Evaluation is still in progress. For the sake of completeness, here are the results so far:

  • ApPHP Hotel Site. License issues. Ruled out.
  • CultBooking. Orphan project. Insufficient documentation. Ruled out.
  • Firefly Sure Book: Orphan project. Insufficient documentation. Bugs. Ruled out.
  • Hotel Druid: GNU Affero License issues would need to be discussed. Possibility.
  • Solunas Hotel Management. Orphan project. Insufficient documentation. Not ruled out.

Here's a screenshot of Hotel Druid:


More remarks will go here.

hotel2nite — Suggested model

ziyadb and OldCoder imagine hotel2nite as follows. Everything here is open to discussion:

There will be three primary interfaces: one for the admin (or site owner), one for customers who wish to book rooms, and optionally one for hotels or spas to add rooms themselves.

The admin UI will have elevated, or global, privileges that allow the admin to control all modifiable features and parameters. For example. the admin will be able to add or remove listings regardless of hotel or spa and to modify parameters for all rooms at all locations; cost, smoking vs. non-smoking, availability of gym, etc.

The user UI will display room listings and allow customers to book rooms.

We recommend that users not be required to register and log-in simply to view listings; keeping the system open to this extent will promote usability and convenience. However, at the client's discretion, users may be required to register and log-in to see special prices and/or to book rooms.

The user UI will include a search function. Features may range from basic to sophisticated based on the budget. There will be a regular list layout to display search results. Each list item will have a room or spa page of its own.

Search filters are to be discussed. Examples might include:

  • Location
  • Price range
  • Smoking vs. non-smoking
  • Free Wireless Internet
  • Minibar
  • Refrigerator
  • Availability of gym, sauna, "fitness" or "wellness" center, etc.
  • Shower only or full-size bathtub
  • Heated swimming pool
  • 24-hour room service
  • 24-hour restaurants

Room or spa pages may link to About pages that provide additional information about associated facilities. Some or all of the pages at these levels may support the use of branding elements and/or marketing material of different types.

If the hotel/spa interface is implemented, it will be similar to the admin interface but limited to locations and parameters associated with each hotel or spa.

hotel2nite — Proposal

A first phase for this project might be to design five sample pages and provide prototypes of these pages:

  • A preliminary homepage to be presented to customers. This would include either real or simulated branding elements.
  • Sample non-operational search form
  • Simulated search results page with one working results link
  • One simulated room page
  • One hotel About page linked from the the room page

The following additional pages could be added to the first phase or handled in a second phase:

  • Site owner Admin UI page(s)
  • Customer UI page(s) for orders
  • Hotel and/or Spa Admin UI page(s)

The design process will focus on optimizing the layout; the most important aspect, as it will largely define the interface and shape how the site as a whole is perceived.

Some of the pages will connect to each other to a limited extent but they will not be operational in a genuine sense.

Presently, it appears that the prototype pages will be done using Ruby on Rails plus some static HTML. This is subject to change.

The code for the prototype pages will be SM's and/or the client's to extend, reuse, or resell. The developers will retain similar rights aside from elements related to branding and trademarks. Licenses for FOSS components used will take precedence where applicable; this issue would be discussed and documented where necessary.

The cost for the first set of prototype pages listed above, including design and code, is presently estimated to be $3,000 U.S. If the admin and/or order pages listed above are added, this will increase costs.

If SM would like to consider additional approaches such as implementations that are limited to back-end components, this can be discussed.

RefX HTML Mail


OldCoder says: Interest has been expressed in attaching an image to email that is sent out by the RefX system. This should be a straightforward task. It will involve adding support for HTML Mail. After this is done it should be possible to style mail, to include images, and to add attachments.

The ultimate goal will be to make it possible for SM designers (Richard or others) to define the style used for mail and/or to select images using procedures they are accustomed to. This may or may not be possible for the first pass.

This task can proceed whenever it is authorized. It will be organized much like the process I used to add the base email feature. I'll spend 2 to 6 hours on initial work. I'll report results subsequently and wait for decisions regarding how to proceed. To keep SM's costs down it will be helpful if GG is available part of the time in IRC to review intermediate results and comment

RefX Meeting Invites


SM says: The client is insisting we provide an email function to go with their meeting invites. They also say we need to sort out the fluency of the site. They say some areas are devoid of information. Other areas don't make sense. The main issue they have though is the email of meeting invites.

OldCoder says: Regarding "fluency" and "information", I agree. Perhaps GG could define a set of changes that would improve the framework. We'd select the ones that provided the most improvement at the least cost and proceed with those.

OldCoder adds: GG has pointed out problems that occur when browsers based on WebKit are used to access the RefX framework. Those problems should go on the RefX list.

OldCoder says: Regarding email for meeting invites, the feature sounds fine.

RefX is an incomplete framework. Therefore, as with the referral email feature I added previously, I will not be able to assess feasibility or costs until work begins. However, the referral email feature I added seems to operating correctly. The "invite email" feature will probably be O.K. as well.

As with other RefX changes, I'll ask that GG be available part of the time in IRC to review intermediate results and comment

Note: To keep costs down, for the "invite" mail feature and most RefX issues, I'll need access to one of the original developers: Mark.

Mark has communicated with me. If RefX work continues, I feel that he and I may work out an arrangement related to exchanges of information. Essentially we may trade ideas in a mutually beneficial manner.

For the present, though, SM may need to maintain a formal agreement with Mark's firm. Mark has indicated that absent a formal agreement with SM or an informal arrangement with me, he may not be able to comment on RefX much longer.

Note for Gordon


Gordon, how are the puppies doing?

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License