Designing an on-line scheduling system

[Areeda]

In this thread we discussed the on-line scheduling systems out there.

In this thread I'd like to bat around the idea of an open source collaboration to develop a new one from scratch. My motivation is that we have a large group of people experienced with all aspects of such a system and a lot of software expertise.

I do realize from the beginning that this would be a lot of work on a product that has been done many times. Right now it's just a mental exercise to see what we want. It may very well be too much work for too little improvement over what's out there. On the other hand we may be able to come up with a level of integration that honestly reduces the work of managing a partnership, club or FBO.

I'll start:

1. Target users (scalability):

Right now I'm in a 2 person partnership, a 4 person partnership and a 100+ member club, so it has to cover at least that range.

Some of the record keeping features may interest a sole-owner.

I see no reason why it couldn't scale to a large club or FBO with many more pilots and aircraft.

2. Access and security:

Certain features such as creating/updating/deleting a schedule need as wide an access as possible. So web browser (computer and smart phone), unattended voice telephone, and SMS should be supported.

Other features such as member management, document management would be web only.

I also see features such as pilot personal information, billing, maintenance records that require more security than I'm comfortable with in an open web based application. I see these done with desktop applications and private databases (details to be developed).

3. Usage Models:

Here I think the primary difference is based on the level of trust of the pilots.

• Individuals and partnerships where everyone is trusted
• Clubs with a volunteer board of directors would have pilots and managers. Pilots would still have be able to do most things but the managers would be controlling the operation.
• FBO with a on-site dispatcher, billing would be done after each flight.
• I don't know if there is another level like a business with multiple airports.

4. Features:

• Scheduler: resources and reservations
• Flight records: exports to billing and electronic logbook programs
• Member records: flight review, medical dates.....
• Member billing:
• Accounting records:
• Maintenance records: fitness for flight (squawk management, inspection currency), electronic logbook for aircraft
• Document manager: access to checklists, POH, club rules, and such
• Possibly forum, blogs
• Possibly photo database

(I have to go meet my first student. More on this later).

5. Implementation, programming environment, version control, testing, and distribution

I don't want to discuss this stuff until we make the decision to actually do this.

PLEASE let's use this to discuss WHAT we want it to do not HOW we're going to do it.
Joe

 

[CJones]

VERY interesting idea. Too bad I already have my projects started for my 'Databases' and 'IS Analysis & Design' classes this semester or I could use this as a working project and get some extra resources thrown at it.

I had been kicking around the idea of writing an online logbook app that would allow you to download data from Garmin x96 GPS's and save the track log (via Google Maps overlay) with each logbook entry. Don't know if that falls within the scope of this project or not, though.

 

[Areeda]

VERY interesting idea. Too bad I already have my projects started for my 'Databases' and 'IS Analysis & Design' classes this semester or I could use this as a working project and get some extra resources thrown at it.

really. Dual use projects are very good for justifying how much time they take.

I had been kicking around the idea of writing an online logbook app that would allow you to download data from Garmin x96 GPS's and save the track log (via Google Maps overlay) with each logbook entry. Don't know if that falls within the scope of this project or not, though.

I've been kicking around a logbook app also. I did do an analysis of the MFD logs from the cirrus that exports to logbook pro and google earth.

Just to show what a geeky nerd I really am, I have an airport database and calculate civil twilight so I can get airports, and number of day and night landings. (I know I need help)

I struggled with the question of if a logbook app should be on-line or desktop. So far my design says a combination and this relates to security of this project.

The problem with an on-line logbook is that I really don't want random people mining it for inconsistencies, same here with maintenance records and billing, and .... There is always the issue of security and in the worst case subpoena. Now I have to say I'm only worried about inadvertent transcription errors, of course, but before you see it I want to make sure it's complete and accurate.

On the other hand the advantage of an on-line logbook is that I can update it anywhere.

So what I thought was a good compromise is the on-line features are temporary. The full and complete database is local and encrypted. So you can make entries on-line but once they are downloaded and successfully entered in the "secure" database they are deleted from the on-line one with possibly summaries available on-line.

Note this does not decrease my desire for security of on-line databases in the least. It only acknowleges that there may be people, smarter than me, that are more intrested in accessing it than I am keeping it from them,

Joe

 

[Areeda]

Reading my first post, the biggest question that I have is what the *&^%$ could you do with SMS that you don't want a voice menu system to do.

First of all, voice menu systens are the work of the Devil. All of the negatives of dealing with people with none of the positives. Most implementations were designed by the Marquis de Sade to make me miserable.

SMS is, well, a one way thing usually. My #1 feature of this system would be:

I'm on my way home, late already, and Clearance Delivery says "Bugsmasher 123, center advised a 30 min delay, say intentions". Regardless of the truth, instead of "find the SOB and stangle him", I say "roger". What I'd like to do is text the system with "L 1h". In my mind it would recognize my phone number, and the fact I have the plane reserved and my message. It extends my reservation by 1 hour and if someone has the plane reserved it follows their notification configuration and either texts, calls, email or some combination and tells them the idiot (me) before them is probably going to be late returning.

Joe

 

[schmookeeg]

As I mentioned, I had already written our schedule system -- it's old "comfy" tech, ASP Classic on MSSQL -- but it could provide a kernel for a project like this to grow out of. I'd gladly donate it, but I'd need a non-criticize agreement since it has been cobbled together as needs require, plus ASPc is a hideous language for structure.

Is the point of this exercise to provide a new and free product for flight clubs / schools who don't want to pay for same, or is there a major shortcoming in the current offerings that you're trying to fill?

I have some free time to donate to this project if it's in ASPc/.NET/PHP, but my free time is in fits and starts. I'd love to participate in any way you need me, but I don't have a lot of guidance to offer, since my schedule works for my needs

 

[Areeda]

As I mentioned, I had already written our schedule system -- it's old "comfy" tech, ASP Classic on MSSQL -- but it could provide a kernel for a project like this to grow out of. I'd gladly donate it, but I'd need a non-criticize agreement since it has been cobbled together as needs require, plus ASPc is a hideous language for structure.

Thanks for the offer. At this point I'm not interested in getting anything done.

Is the point of this exercise to provide a new and free product for flight clubs / schools who don't want to pay for same, or is there a major shortcoming in the current offerings that you're trying to fill?

Lets say that I believe that the probable monetary return on investment will be way less that getting a job at McDonalds flipping burgers.

What I'd like to get out of this exercise is:

• A concept that would use a computer to actually reduce the time spent managing the partnerships and club that I belong to, while at the same time making that effort more productive.
• An ideal for comparison to the existing products.

I don't want to discount the idea that this might actually produce that killer app that will pay for my flying until I can't fly any more but that is not the reason to do it.

As far as free. It believe there is capitalistic rationale to the open source model. Yes people get to use it for free and from them we get valuable criticism of the design, bug reports and suggestions for improvement. I also think there can be money made from providing the service of a fully functional, managed system where we are obligated to respond to the criticisms, and suggestions.

I have some free time to donate to this project if it's in ASPc/.NET/PHP, but my free time is in fits and starts. I'd love to participate in any way you need me, but I don't have a lot of guidance to offer, since my schedule works for my needs

Right now I'm really much more interested in what are your needs and how your current system meets them than I am in how finding volunteers.

Mike -- I am based at El Monte most of the time and keep another plane at Camarillo. You are almost spitting distance. How about we get together for a discussion of this and some flying?

Joe

 

[CJones]

really. Dual use projects are very good for justifying how much time they take.

Exactly. I'm using my "IS Analysis & Design" for where I work as we're getting ready to change web hosts and roll out a newly designed site. Might as well get paid for doing homework.

For my 'Databases' class, I'm helping my sister-in-law out who works for a non-profit that has an annual live & silent auction fund raiser event. She needs to be able to track bidding numbers, donations, item cost vs sell price, donators and their annual vs. total donations, mailing lists, etc. So I'm working on a scalable Access database for them to use.

I've been kicking around a logbook app also. I did do an analysis of the MFD logs from the cirrus that exports to logbook pro and google earth.

I haven't done any analysis yet, just some "Hmmm, I could make it do..." type of thinking. My 'make my first million $' idea was to market it to Garmin for them to include with their x96 model GPS units.

Just to show what a geeky nerd I really am, I have an airport database and calculate civil twilight so I can get airports, and number of day and night landings. (I know I need help)

Where do you compile your airport database from? I'm using one on my personal site that I borrowed from someone else with identifiers, name, lat/long, but I recently noticed that one of the airports I put in has a new identifier so I need to update my database.

I struggled with the question of if a logbook app should be on-line or desktop. So far my design says a combination and this relates to security of this project.

My initial thinking was that away from their desktop, the user would only be able to view their logbook - no editing available. That way they can show their flights to family, coworkers, etc., but they can't actually add/edit anything until they get home, which makes sense b/c they probably won't be able to download their track until they get home anyway.

What's your preferred development platform? I was thinking .NET would be good for a combo online/desktop app., but that's just because that's the only environment that I have any noticeable experience with.

 

[schmookeeg]

Mike -- I am based at El Monte most of the time and keep another plane at Camarillo. You are almost spitting distance. How about we get together for a discussion of this and some flying?

Joe

Sounds like a good plan -- especially now that I understand the goal and like it a lot. Next week is best for me, and can do the following weekend as well -- PM me with some time and place.

Also I "work" at AJO, based at HHR, live in Playa Del Rey, if that centers the thing any better for ya

 

[midlifeflyer]

Joe, have you seen this one?

http://ors.sourceforge.net/

I've been using it to book my instruction for several years.

 

[CJones]

Joe, have you seen this one?

http://ors.sourceforge.net/

I've been using it to book my instruction for several years.

That looks like a good ballpark starting point, but it looks like it hasn't been updated since 2006. Lots of new dev toys have been implemented since then. Gentlemen, we can rebuild him (it). We have the technology.

 

[flyingcheesehead]

Joe,

After spending a few hours banging on ScheduleMaster today, I have only one thing to say:

Don't forget about the user interface.

Make it clean-looking and easy to use. IMHO, if you need a manual, a FAQ page (except for rare instances), etc. your user interface needs work.

 

[Areeda]

Where do you compile your airport database from? I'm using one on my personal site that I borrowed from someone else with identifiers, name, lat/long, but I recently noticed that one of the airports I put in has a new identifier so I need to update my database.

I get the US airport info from http://www.faa.gov/airports_airtraffic/airports/airport_safety/airportdata_5010/

I also have one similar to yours for International airports but it hasn't been updated in a while

My initial thinking was that away from their desktop, the user would only be able to view their logbook - no editing available. That way they can show their flights to family, coworkers, etc., but they can't actually add/edit anything until they get home, which makes sense b/c they probably won't be able to download their track until they get home anyway.

I look at it a little differently.

I really don't want to put my whole logbook (pilot or airplane) on someone's website not even my own. A summary is OK

What's your preferred development platform? I was thinking .NET would be good for a combo online/desktop app., but that's just because that's the only environment that I have any noticeable experience with.

I'm not sure and I really want to leave that decision for later. I'm leaning toward something more cross-platform than .NET. Also my experience with it is limited, and the development tools are expensive.

Felix got me started on Ruby on Rails but I'm still learning. I have a fair amount of PHP and Java experience.

The implementation details need to wait until we figure out what exactly we want to do IMHO.

Joe

 

[Areeda]

Joe, have you seen this one?

http://ors.sourceforge.net/

I've been using it to book my instruction for several years.

I have not seen that one, Mark.

It does seem to have some nice features. I will download and try it out. It may very well replace PHPScheduleIt for our airplane and my instructor time.

Joe

 

[Areeda]

Joe,

After spending a few hours banging on ScheduleMaster today, I have only one thing to say:

Don't forget about the user interface.

Make it clean-looking and easy to use. IMHO, if you need a manual, a FAQ page (except for rare instances), etc. your user interface needs work.

Good point.

I like to use what is now called Extreme Programming to develop programs like this. We used to call it Rapid Prototyping or Step-wise Refinement.

The idea is to get a minimally functional version 0 with much of the user interface out to the users as soon as possible. Then respond to their feedback. The advantage is that without a big investment in V0.0 there's little downside to throw it out and try again to get it right, of course some it will be reused.

I'll argue a bit with your "no manual or FAQ needed".

I certainly understand the "Columbus didn't have to ask for directions, why should I" concept (ask my wife).

The problem is the law of primacy. You have a nice clean easy interface and 5 people sit down and do the same task 5 slightly different ways. As the package evolves these 5 people will continue to do the same task the same way that was the most obvious to them on day 1.

That's not all that bad if that's all they need to do and it all the ways are reasonably efficient. Certainly every new pilot in the club should not need a 3 day seminar on how to schedule an airplane.

The problem comes in with increased flexibility and functionality especially for the managers that need to work with the more complicated aspects.

Anyway, I'm not saying make it more complicated than absolutely necessary, nor am I saying the basic scheduling functions should be so obvious that a new pilot needs more than a url and a password to schedule.

Joe

 

[CJones]

I get the US airport info from http://www.faa.gov/airports_airtraffic/airports/airport_safety/airportdata_5010/

Perfect.

I look at it a little differently.

I really don't want to put my whole logbook (pilot or airplane) on someone's website not even my own. A summary is OK

What would you include in the 'summary'? I like the idea of being able to show tracks to coworkers, but I agree that full 'time logged & flight description' aren't necessary.

I'm not sure and I really want to leave that decision for later. I'm leaning toward something more cross-platform than .NET. Also my experience with it is limited, and the development tools are expensive.

Felix got me started on Ruby on Rails but I'm still learning. I have a fair amount of PHP and Java experience.

The implementation details need to wait until we figure out what exactly we want to do IMHO.

Joe

True. Just curious what your preferred environment was. I'm spoiled because I get all the MS tools for free through the MIS Dept at school. I think the legalities prevent me from using them for 'for profit' development, though. If I need something done quickly, I'll use PHP and have the .NET page redirect to that page, especially when talking to a database. Haven't tried Ruby on Rails yet, but you're the second person that has recommended it.

 

[AuntPeggy]

Joe, have you seen this one?

http://ors.sourceforge.net/

I've been using it to book my instruction for several years.

Just uploaded this to my new host. First application there. Tons of syntax errors due to PHP version incompatibility. sigh.

In this thread we discussed the on-line scheduling systems out there.

PLEASE let's use this to discuss WHAT we want it to do not HOW we're going to do it.
Joe

I'm interested in a very different scheduling application for the Animal Rescue Flights. Moving a variety of packages (animal) from points A, B, C to points D, E, F using various pilots at various airports with various performance and capacity, taking into consideration weather and pilot preferences such as cheap gas and towered/non-towered. It needs to have some sort of what-if capability.

Is this too far a reach?

 

[Areeda]

I'm interested in a very different scheduling application for the Animal Rescue Flights. Moving a variety of packages (animal) from points A, B, C to points D, E, F using various pilots at various airports with various performance and capacity, taking into consideration weather and pilot preferences such as cheap gas and towered/non-towered. It needs to have some sort of what-if capability.

Is this too far a reach?

Well while we're dreaming of what we can do, I don't see anything as out of the question.

I'm thinking about how Angel Flight works (at least a couple years ago when I donated my time to them instead of practically donating it to students).

That system had missions and pilots, rather than resources and pilots. A mission is a one time deal and once it's complete it goes away unlike resources which are available. Also there are a lot of missions vs limited resources and the need is for the pilots to find compatible missions, granted that often the volunteers have to find (read beg for) compatible pilots.

I'm not sure but it seems like a reasonable module. Not more different from scheduling airplanes than tracking maintenance or accounting.

Joe

 

[KennyFlys]

One feature that would be usable for our school is setting specific schedule blocks. We schedule all lessons in 2.5 blocks each starting at 0800, 1030, 1300, 1530 and 1800. Every other week, we plug in a single hour at 1300 for a CFI meeting.

This doesn't appear to be an easy feat in other applications I've looked at.

 

[flyingcheesehead]

Joe, have you seen this one?

http://ors.sourceforge.net/

I've been using it to book my instruction for several years.

Assuming "ORS" stands for Online Resource Scheduler, that's what the local FBO uses, and IMHO it sucks sucks sucks. (Again, still better than FlightSchedule Pro!) It has improved since they first installed it. Luckily I don't have to use it often since I almost never fly their planes and I'll usually just call my CFI directly to schedule with him. IIRC, it's reasonably easy to schedule but a pain in the butt to edit said schedule - I recall it thinking I was deleting instead of just changing (as if it was running a delete and an add behind the scenes) and it gave me all kinds of dire warnings about how I was going to be charged for the flight anyway (and the FBO doesn't even charge for no-shows).

Maybe I'm biased because I was going to write a scheduler for them before they found ORS (who can compete with free? ), but I find ORS to be a below-average solution.

 

[flyingcheesehead]

I'll argue a bit with your "no manual or FAQ needed".

I certainly understand the "Columbus didn't have to ask for directions, why should I" concept (ask my wife).

The problem is the law of primacy. You have a nice clean easy interface and 5 people sit down and do the same task 5 slightly different ways. As the package evolves these 5 people will continue to do the same task the same way that was the most obvious to them on day 1.

That's not all that bad if that's all they need to do and it all the ways are reasonably efficient. Certainly every new pilot in the club should not need a 3 day seminar on how to schedule an airplane.

The problem comes in with increased flexibility and functionality especially for the managers that need to work with the more complicated aspects.

Well, the "extreme programming" won't work too well with good UI design, IMHO. Those first 5 guys are gonna be mad if you make something "better" for a new user because they'll have to learn a new way to do it.

The other thing is that programmers, myself included, generally write for features, and the UI becomes whatever method the programmer could write easily. Rarely is a UI that's easy to use from an end-user perspective easy to write or design!

For that reason, I'd suggest you figure out all of the features you want to have in V1.0, 2.0, and 3.0 before you even start. Then, group them in a way that makes sense - And that means put them in the first place you'd think of, then test some "dummy" software on some "dummies" (people who have nothing to do with the product) and make it work however most of them tried to make it work. Then, when V2 and V3 come out, your users don't have to re-learn things. Later on, if you need to make major modifications, you should be able to get away with one big mod per major version release without alienating folks too much.

Some parts of the UI are simply look and feel. For example, aircraftclubs vs. schedulemaster, I much prefer the look of aircraftclubs:

Aircraftclubs, on top, has a much cleaner look, and that makes it easier to use - Click on an airplane to schedule it, change the options for the current calendar at the top of the frame, and if I want something else the calendar views are all nicely grouped at the top of the left-hand frame and other pages are lower down. Schedulemaster is kind of a mess - In particular, the box above the schedule grid is poorly organized, the schedule grid itself is not easy on the eyes, there's no way I can tell to get more days without crunching the grid down, and the navigation bar at the top hides up to three layers of navigation to get to some features. Yuck! Needs work.

Bottom line, the easier it is to use, the more users will like it, the more free positive word of mouth your product gets. It absolutely astounds me how many companies just don't get that. "To speak to our customer prevention department, please press 1..."

 

[midlifeflyer]

I have not seen that one, Mark.

It does seem to have some nice features. I will download and try it out. It may very well replace PHPScheduleIt for our airplane and my instructor time.

Joe

As I recall, Jeremy Shaver, one of the developers was a pilot and the project started in a thread just like this one. I think I began using it in 1.0.

Just uploaded this to my new host. First application there. Tons of syntax errors due to PHP version incompatibility. sigh.

Interesting. The server I use is running PHP ver 5.2.8. Is yours running something really old or something very new? Are you sure is not permissions, rather than version?

 

[Areeda]

Before I start, I want to say I appreciate the discussion. I'm going to disagree with you, but heck if I can't defend my position I need to change it.

Well, the "extreme programming" won't work too well with good UI design, IMHO. Those first 5 guys are gonna be mad if you make something "better" for a new user because they'll have to learn a new way to do it.

Maybe my example was not the best. I think the EP model is one of the better ways to develop a good UI, because of the almost immediate feedback. No matter how much time I put into a design I find what's obvious to me is not alway intuitive for someone else.

Perhaps a greater emphasis on the idea that "cobble together something quick and dirty and see if it flys" is a technique used in the design process that allows more focused quality feedback from end user without programming skills. It is not a development stategy.

It is much easier to see a mock up like this and say I like this, hate that and can't think of any reason to ever press that button, than it is to review a design document.

The other thing is that programmers, myself included, generally write for features, and the UI becomes whatever method the programmer could write easily. Rarely is a UI that's easy to use from an end-user perspective easy to write or design!

Yes and no. In my mind there are multiple question we have to answer to effectively implement a feature.
#1 is that feature needed. A project like this where the developer is also an end user makes it easier but still not clear.
#2 how will the feature work
#3 how will it be presented to the user

For that reason, I'd suggest you figure out all of the features you want to have in V1.0, 2.0, and 3.0 before you even start. Then, group them in a way that makes sense - And that means put them in the first place you'd think of, then test some "dummy" software on some "dummies" (people who have nothing to do with the product) and make it work however most of them tried to make it work. Then, when V2 and V3 come out, your users don't have to re-learn things. Later on, if you need to make major modifications, you should be able to get away with one big mod per major version release without alienating folks too much.

We're a lot closer on this point.
In general I'm not very good at figuring out next year's priorities so I don't design for V1.0, 2,0 and 3.0. I tend to design for 3.0 and get an idea what would I want it to do if resources were not limited. Then say what does it have to do to be useful and prioritize the order it will be implemented. Subsequent revisions shuffle those priorities and add new features based on feedback and requests.


The idea of logging the way people do things to (re)design the UI is intriguing. I assume that by “people who have nothing to do with product” you mean people who have nothing to do with the development of the product. I think they should be our target users.

Some parts of the UI are simply look and feel. For example, aircraftclubs vs. schedulemaster, I much prefer the look of aircraftclubs:




Aircraftclubs, on top, has a much cleaner look, and that makes it easier to use - Click on an airplane to schedule it, change the options for the current calendar at the top of the frame, and if I want something else the calendar views are all nicely grouped at the top of the left-hand frame and other pages are lower down. Schedulemaster is kind of a mess - In particular, the box above the schedule grid is poorly organized, the schedule grid itself is not easy on the eyes, there's no way I can tell to get more days without crunching the grid down, and the navigation bar at the top hides up to three layers of navigation to get to some features. Yuck! Needs work.

We are pretty close on this one too, but...


I certainly agree it is not about how many features the program has but rather how many features are used (think Microsoft Office). And that depends on not only how easy they are to use but how easy they are to find. In other words how natural is it to think that I should do this next and have a control named similar to what I just thought of. That is ease of use, intuitive design, and clean interface.


I do believe that aesthetics of the presentation are important and I certainly am not going to defend the way ScudMaster presents things. Dilbert showed the perfect product “Our product is so easy to use it has only one button and not only that but we push it before we ship it”. Unfortunately I've never come close.


In my mind, as important as look and feel is, it can still be overrated. I am much more of a substance over form kind of guy and believe the most important thing is does it get the job done. For example I've recommended June Bonesteel's oral prep guide to people and have had the response I would never order that book her website sucks.


I've also seen way to much time spent on the shape of buttons and the shade of blue used for the background. I see very little reason to have 10 skins for a program that change the color, font and buttons but do nothing to change the organization of the UI.

Bottom line, the easier it is to use, the more users will like it, the more free positive word of mouth your product gets. It absolutely astounds me how many companies just don't get that. "To speak to our customer prevention department, please press 1..."

Absolutely.


I wrote way to much in this post. Sorry.
Joe

 

[Areeda]

One more point while I wait for the student to preflight:

Some parts of the UI are simply look and feel. For example, aircraftclubs vs. schedulemaster, I much prefer the look of aircraftclubs:


Aircraftclubs, on top, has a much cleaner look, and that makes it easier to use - Click on an airplane to schedule it, change the options for the current calendar at the top of the frame, and if I want something else the calendar views are all nicely grouped at the top of the left-hand frame and other pages are lower down. Schedulemaster is kind of a mess - In particular, the box above the schedule grid is poorly organized, the schedule grid itself is not easy on the eyes, there's no way I can tell to get more days without crunching the grid down, and the navigation bar at the top hides up to three layers of navigation to get to some features. Yuck! Needs work.

I agree with your analysis. SM could really organize and present things much better. A big part of their problem IMO is that new features are continually added without rethinking the UI.

A lot of my motivation for this project is because I hate having to make a choice between several products that do essentially the same thing, some with features I need and a crappy interface, others with better interfaces lacking essential functions, others at better price points with mediocre interfaces and feature sets.

In the long run, I believe support is the most critical thing. If the product continues to evolves in response to needs and is continually refined to present things well, it will succeed.

Joe

 

[AuntPeggy]

Interesting. The server I use is running PHP ver 5.2.8. Is yours running something really old or something very new? Are you sure is not permissions, rather than version?

Identified PHP as Version 5.2.8
It looks like it is merely a matter of downloading files, changing $HTTP_POST_VARS to $_POST and uploading the changed files.

 

[AuntPeggy]

Well, the "extreme programming" won't work too well with good UI design, IMHO. Those first 5 guys are gonna be mad if you make something "better" for a new user because they'll have to learn a new way to do it.

Consider this a learning experience?

The other thing is that programmers, myself included, generally write for features, and the UI becomes whatever method the programmer could write easily. Rarely is a UI that's easy to use from an end-user perspective easy to write or design!

Bottom line, the easier it is to use, the more users will like it, the more free positive word of mouth your product gets.

It is much easier to see a mock up like this and say I like this, hate that and can't think of any reason to ever press that button, than it is to review a design document.

In my mind there are multiple question we have to answer to effectively implement a feature.
#1 is that feature needed. A project like this where the developer is also an end user makes it easier but still not clear.
#2 how will the feature work
#3 how will it be presented to the user

I've also seen way to much time spent on the shape of buttons and the shade of blue used for the background. I see very little reason to have 10 skins for a program that change the color, font and buttons but do nothing to change the organization of the UI.

I like the blue on this board.

 

[flyingcheesehead]

Before I start, I want to say I appreciate the discussion. I'm going to disagree with you, but heck if I can't defend my position I need to change it.

Well, if you disagreed with me, you didn't disagree much!

Maybe my example was not the best. I think the EP model is one of the better ways to develop a good UI, because of the almost immediate feedback. No matter how much time I put into a design I find what's obvious to me is not alway intuitive for someone else.

I have the same problem sometimes, but that's usually because I start coding first and designing later so the lazy coder in me goes for the design that's easiest to code. This is also why it's important to get feedback early on from your eventual end users.

It is much easier to see a mock up like this and say I like this, hate that and can't think of any reason to ever press that button, than it is to review a design document.

Bingo. The first step is to just draw boxes for the features and lines for how they should be linked together. Then, make a mockup with that logic behind it, make it easy to look at and easy to find things, and go from there.

In general I'm not very good at figuring out next year's priorities so I don't design for V1.0, 2,0 and 3.0. I tend to design for 3.0 and get an idea what would I want it to do if resources were not limited. Then say what does it have to do to be useful and prioritize the order it will be implemented.

Yup, that's exactly what I meant. If you know what features you'd eventually like to have in 3.0, you can design the UI for 1.0 with the future in mind. Effectively, you'd design the UI for 3.0 as well, and leave logical spots to plug in the new features as you move from 1.0 to 2.0 to 3.0.

The idea of logging the way people do things to (re)design the UI is intriguing. I assume that by “people who have nothing to do with product” you mean people who have nothing to do with the development of the product. I think they should be our target users.

Bingo. You ask them to do something, say, "schedule an airplane." What's the first thing they click on? Does that thing start the process of scheduling an airplane? If not, it should. There's also nothing wrong with having multiple ways to accomplish the same thing so that everyone's first try actually works.

I certainly agree it is not about how many features the program has but rather how many features are used (think Microsoft Office).

Funny, I was thinking of Office when I wrote that message. Office is a great example of bad design. There's a ton of features, most of which many people don't use, and many of which most people don't even know exist. Every time a new version comes out, things are moved around the screen, keyboard shortcuts change, and you have to learn how to use it all over again.

In my mind, as important as look and feel is, it can still be overrated. I am much more of a substance over form kind of guy and believe the most important thing is does it get the job done.

I would say that both are equally important. You're right that look and feel can be overrated, but usually it is underrated. A great UI is worthless without features to back it up, but all the features in the world are worthless if the UI discourages their use. Good UI *and* good features will result in a product that sells extremely well.

For a great example of this, look at the iPhone. If you search threads from a couple of years ago, I think it was EdFred who said "My phone already does everything the iPhone will do." In fact, mine did too - But I had bought my phone for a lot of those features, and ended up not using them because it was a pain. Whereas the iPhone only had a few new features not seen in previous phones, it had a UI that was head, shoulders, torso, and legs above any previous phone, and they've been wildly successful with it.

For example I've recommended June Bonesteel's oral prep guide to people and have had the response I would never order that book her website sucks.

Well, if her website is preventing sales of her book, then clearly she needs a major revamp of the UI there. A truly successful UE (I was gonna say UI, but this is where User Experience) design will make the product so easy to buy and use that it's almost more difficult NOT to buy and use the product.

I've also seen way to much time spent on the shape of buttons and the shade of blue used for the background. I see very little reason to have 10 skins for a program that change the color, font and buttons but do nothing to change the organization of the UI.

Amen. "UI" isn't colors. It's organization of the controls. However, "colors" can have something to do with it (for example, on AC vs. SM, AC has the hours alternating white and gray - easy to look at - while SM is all white with lines all over the place). The visual design should simply be uncluttered and focus the user's eyes on the most important controls and information.

 

[Areeda]

For a great example of this, look at the iPhone. If you search threads from a couple of years ago, I think it was EdFred who said "My phone already does everything the iPhone will do." In fact, mine did too - But I had bought my phone for a lot of those features, and ended up not using them because it was a pain. Whereas the iPhone only had a few new features not seen in previous phones, it had a UI that was head, shoulders, torso, and legs above any previous phone, and they've been wildly successful with it.

Kent,

The counter example is my wife's son who has an iPhone. I asked should I trade my POS Verizon Razr for an iPhone? How does it work?
Response:
It sucks around here. I put it in my pocket and the display cracked. OK I can buy a new one but why? I can't make phone calls in places that the ****ty f-ing crap that comes from Verizon can. They want another big bag of money because I made the big mistake of putting their product in my pocket.

What does the thing I carry around have to do?

Joe

 

[wildwobby]

I'd be willing to participate in this.

I have a pretty good knowledge of: php, javascript (prototype/mootools), (x)html, python (Django), Objective-C (Cocoa), CSS, MySQL, etc..

I would help out with refining the system after the base is already started.

Lets get this going!

 

[flyingcheesehead]

The counter example is my wife's son who has an iPhone. I asked should I trade my POS Verizon Razr for an iPhone? How does it work?
Response:
It sucks around here. I put it in my pocket and the display cracked. OK I can buy a new one but why? I can't make phone calls in places that the ****ty f-ing crap that comes from Verizon can.

As for phone calls, well, every carrier has their strong and weak spots. From my days of driving around the country, I can tell you two things: Only Verizon and AT&T have truly nationwide coverage, and when I switched from a Nokia phone on Verizon to a Sony Ericsson on AT&T I noticed an overall improvement. Not a huge one, mind you - Verizon's network is pretty good - But a noticeable one at least. No carrier will be the best everywhere. But that has nothing to do with the iPhone or its user interface.

As for the screen - Did he try to take it back to the Apple (NOT AT&T) store? They're pretty good about replacing them if that sort of thing happens, especially if they're new. (Ask Spike.)

That said, I think that's a pretty rare occurrence. I can state that the screen on my iPhone is plenty strong - I keep it in my pocket almost all the time, with no cover. Mostly it gets rattled around with coins and keys, though yesterday I had it in the same pocket as the business end of a small claw hammer and a screwdriver while I was working on top of a ladder. I've dropped it countless times, had it in my pocket while sleeping and surely rolled over it quite a few times, purposely taken a key to it (ask Andrew, he took video!) and after all that, not only have I not broken it, I've managed a single solitary scratch. Tell me any other phone is gonna live up to that level of abuse...

But I still don't see what that has to do with the user interface?

 

[Areeda]

I really like the philosophy of design discussions and hope that doesn't stop.

To move on in an object oriented way let's discuss objects. this is a very rough first go at it.

People, those who can access the site:

• Idenitity - user name, real (damn it) name, password
  • what about biometrics should we use things like a fingerprint scanner?
• Contact Info - email, phone, sms, instant messaging (yeah a bunch), snail mail address - almost all must be optional

Subclasses of People, privileges and features are assigned by admins

• Consumers of resources, subclass or property?
  • billing information.
• Pilots
  • License, medical, FR, IPC records and due dates
  • checkouts, permission to schedule individual resources
• Managers
• Dispatchers
• Mission requestors

Resources, things that can be scheduled

• Aircraft have maintenance records
• Accessories (headsets, life vests, GPS. what else?) may have accounts
• Instructors may have accounts
• People - may have accounts

Missions,

• Date, route, # passengers, weight, what else?
• Requests from people
• Volunteers from pilots, aircraft

Flights

• Billable, so we need tach, hobbs time
• Loggable, so airports landing
• Fuel, oil usage

Accounts

• I'm going to need some help here. I know how we do it for our partnership and some idea about the club but no idea how to be flexible enough.

Billable things:

• Flights
• Membership
• Missions ?
• use of accessories
• Leaseback

Maintenance Records:

• Squawks
• Scheduled maintenance, done, due
• I don't know if we want electronic airframe/powerplant logbooks

What am I missing?

Joe

 

[wildwobby]

I could host the development process. We need to take a first step as far as creations, and also we have to figure out a version control for collaboration. SVN?

 

[KennyFlys]

Joe,

What about the ability to set specific reservation time blocks that can be modified only by instructors?

A restriction on multiple day rental by anyone other than staff determining availability and suitability.

 

[Areeda]

But I still don't see what that has to do with the user interface?

Not much. I does however prove I shouldn't drink during lunch.

Joe

 

[Areeda]

Joe,

What about the ability to set specific reservation time blocks that can be modified only by instructors?

A restriction on multiple day rental by anyone other than staff determining availability and suitability.

Gosh, I forgot the schedule/calendar object altogether.

Calendars/Schedule:

• Multiple views,
  • resource, date, or user centric.
  • Time frame, day, week, month, year
• Units (1/4, 1/2, hour).
• Start time (any, on the half hour, hour, even/odd hour)
• Permissions - here's where it gets complicated
  • Assigned by groups
  • Dispatchers, Administrators can do anything in the future but only add comments to the past entries
  • Pilots
    • Can schedule resources they have been approved for
    • Can initiate a maintenance schedule for some configurable time say 24 hrs
    • Can extend a schedule, even if someone has it scheduled. I'm not sure exactly how this works but if I'm late returning for weather, maintenance, ATC delays there should be a way to notify the next person and record the issue. I'm also not sure how to keep this from being abused
  • Instructors - I'm trying to figure out how Ken's suggestion would work
    • Scheduled as resources, tied to an aircraft reservation
    • Have privileges to modify these schedules
    • Can set available or black out dates for themselves
• Multiple level standby reservations
• Policies
  • Need to be very flexible and configurable by administrators
  • Should be on a per resource basis
  • Min and max duration, weekday and weekend configurable
  • How far in the future one can schedule
  • Limits on number of schedules a user can make

This is a complicated area because everybody does it differently. For example our club allows 17 day schedules. We also have a special rule that the same person can't reserve the same airplane for more than 3 hrs on a weekend more than twice a month (that one is named after a specific person).

Joe

 

[thepetrostate]

You should have enough information to form a Preliminary Statement Of Work (PSOW)

 

[Areeda]

You should have enough information to form a Preliminary Statement Of Work (PSOW)

Agreed.

Actually I probably have enough information to chew up all my "spare" time for a while.

Joe

 

[thepetrostate]

Agreed.

Actually I probably have enough information to chew up all my "spare" time for a while.

Joe

A PSOW-SOW followed by a good set of Job Requirements would (hopefully) shorten the development cycle for you.

Is it your conclusion that there is a need (market) for a kinder, better OLS?

 

[Areeda]

A PSOW-SOW followed by a good set of Job Requirements would (hopefully) shorten the development cycle for you.

For a project like this, discussions like these are very valuable.

Is it your conclusion that there is a need (market) for a kinder, better OLS?

John,

I believe there is a need, in the sense that I have not found a good solution for either the partnerships or the club I'm in nor the FBOs I've used. The current offerings are helpful but incomplete and often (as Kent would say) provided with user's experiences that suck.

Is there a market that can provide a decent ROI on the development effort? Well that's a different question and I really don't have an answer.

That's why I'm leaning toward an Open Source effort with potential commercial opportunities in support and providing the entire service including Jesse's web servers.

Joe

 

[AuntPeggy]

A PSOW-SOW followed by a good set of Job Requirements would (hopefully) shorten the development cycle for you.

Is it your conclusion that there is a need (market) for a kinder, better OLS?

I'm interested in helping, but not interested in a contract or any other actual commitment.

 

[AuntPeggy]

Missions,

• Date, route, # passengers, weight, what else?
• Requests from people
• Volunteers from pilots, aircraft

Pilots, missions and resources have available/non-available times as well as scheduled times. For example, I am available weekends, or weekdays 6:00 pm to 9:00 pm. I'm not available over Christmas and Easter holiday weeks and my airplane is not available the first week of April.
Missions have route maps.

I'll be contacting our coordinator to get some use cases.

I have available NAS and NFDC data. Currently in the process of writing code converting flat files to database tables. Very slow going as there is little standardization.