On Sat, Oct 24, 2009 at 8:46 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:

>
> How many resources should be available for booking? How would one
> search for them, by keyword? Should the time-slots be fixed?
>

And n Sat, Oct 24, 2009 at 9:30 PM, Thadeus Burgess
<thade...@thadeusb.com>wrote:
> Should time slots be declared before hand? So that a user could only
select from a fixed time > slot?

A- Regarding resources:
How many? for my own use there would be just a few  resources: no more than
10 meeting rooms, 10 machine accesses, 10 devices. But for a general use in
other contexts, I imagine
that this could be many more..
 I imagine the user would select the resource by some form of "resource
picker",
perhaps a simple menu, or perhaps a cascading menu where you first choose
the resource
 category (e.g. room), then the exact resource e.g. (room 43). Instead of a
cascading menu,
this could also be some kind of Ajax autocompletion/suggestion gadget, I
have
no definitive preference. Perhaps the simplest to customize would be the
better
When mdipierro says "search for them by keyword", indeed it's almost the
same thing
("keyword", "category", or even "tag", whatever word you use, it's some form
of
classification).

+ Another (optional) requirement, forgotten in my previous mail:
13) Each resource could be associated with a piece of html (that e.g. would
be callable to provide the users with an explanation about this
resource)....

B- Regarding time slots:
No definitive idea, but as you suggest it, the time slots could be fixed. I
imagine
that the time granularity could be customizable in the Python code. For my
own
use 30mn would be OK, but for others, smaller slots (e.g. 5mn) would be
needed.
I do not know what kind of interaction would be appropriate.
A kind of time picker where the user selects the start time and the end
time?
Or the start time and duration? We can begin with something simple to
implement,
and in subsequent releases propose something more attractive with ajax
feeback etc.

Thanks  &  Regards




On Oct 24, 1:40 pm, Vincent Borghi <vincent.borgh...@gmail.com> wrote:
> Hello,
>
> On Sat, Oct 24, 2009 at 4:45 PM, Yarko Tymciurak <
>

> > resultsinsoftw...@gmail.com> wrote:
> > > On Sat, Oct 24, 2009 at 9:26 AM, mdipierro <mdipie...@cs.depaul.edu
> >wrote:
> >
> > >> We could write one. Can you send more specs?
> >
> > In fact, in my mind, I was looking for an already existant application,
> > but if you are ready to develop a new one from scratch, why not?!
> > Thanks for your responsiveness, and see my requirements below...
> >
> > that is, can you state clearly what you want (and don't want), what
> problems
> >
> > > you anticipate (e.g. expected scheduling conflicts, exceptions - e.g. a
> > > director level person is allowed to override a reservation, and how
> that
> > > should be handled),  the kinds of resources (and pertinent information
> about
> > > them), and the population that will be served by this system (and what
> you
> > > want for them, and their experience).
> >
> > > From there, we can start a conversation to develop specifications.
> The
> > > implementation (e.g. python, web2py, or whatever) then should be chosen
> by
> > > what can best accomplish what you want (for example - you may want a
> level
> > > of interaction that suggests Flash on the client end, or not...).
> >
> > Not really specs, but some requirements follow:
> >
> > 1) I want to be able to easily customize/modify the application myself,
> > and for my personal taste and experience, this simply means that Python
> is a
> > must.
> > This also means that for the rendering, I want no Flash but just
> > html+css+javascript
> > (preferably simple javascript, as I am not a JS guru: that means that the
> > code itself
> > is simple and/or based on a good javascript library that has a simple and
> > clean api).
> >
> > 2) I want something that is simple and light for the
> developer/administrator
> > (i.e. for me).
> > This simplicity is desired when installing the program, as well as when
> > modifying the
> > program, and in my mind this means the app operates either as standalone
> > cgi/wsgi
> > scripts or as a web2py app (ideally, just copy/edit Python scripts, no
> need
> > to run
> > complicated procedures (compile, make, hack the makefile, or setup,
> > buildout, paster,
> > etc)
> >
> > 3) Just a simple, basic, code, without too many or too complex features,
> > would
> > be useful. From such an essential base, a Python developper/app
> > administrator can
> > elaborate as desired additional ad hoc functions.
> >  (I could find php- or perl-based freeware with many (not necessarily
> > useful) features;
> > but I prefer something small but easily customizable/augmentable)
> >
> > 4) Usage scenario:
> > The app would be used by some users (between 50 and 200) to book
> resources.
> > Typical "resource" examples are: meeting rooms; time slots to remotely
> > access to a given computer; laptop or other device offered in a self
> service
> > pool of equipment.
> >     In my case, I plan to manage just some "resources" (5 or 6, perhaps
> more
> > in the future).
> > A resource booking involves mainly 3 things: a resource, a time slot, a
> user
> > (who has booked
> > the resource). Perhaps a comment from the user would be a useful 4th
> > characteristic.
> >
> > 5) Users can consult the reservations already registered for a given
> > resource.
> > As in Google calendar, the user has the choice between several views:
> > perhaps "month",
> > "week", and "agenda" (the linear list of occupied time slots). The user
> can
> > scroll /browse
> > thru the reservation calendar (forward/backward).
> >
> > 6) Users can book a resource: they specify the concerned resource and the
> > desired time slot,
> > and possibly a comment. If the time slot is free, the booking is
> recorded.
> > If the requested
> > time slot is totally or partially unavailable, the booking is not
> performed.
> > The user must chose an available slot.
> >
> > 7) A user can himself cancel (remove) a resource booking he has
> previously
> > performed.
> >
> > 8) As a bonus, a kind of "approver" role can be introduced: the approver
> can
> > tag
> > a resource reservation as "approved" (validated", "acted"...)
> >
> > 9) As a developer, I can customize the code to introduce some form
> > of access control (lists of users authorized...). Authentification is out
> > the
> > scope of the application itself. I'll provide my own checks in the code
> > (perhaps based on the prseence of some cookies previously set by an
> > external SSO system...).
> >
> > 10) A log of operatoons (booking, cancelation) is available for the
> > administrator.
> >
> > 11) Base actions have perhaps hooks associated with them: the
> > developer/administrator
> > can provide his own functions that will betriggered when such or such
> action
> > occur
> >
> > 12) To be continued. The above is just for your reflexion....
> > Keywords are suimplicity, ligntness, code customisability...
> >
> > Yanks and regards
> >
> > >> On Oct 24, 3:49 am, Vincent Borghi <vincent.borgh...@gmail.com>
> wrote:
> > >> > Hello
> >
> > >> > I am looking for a simple and light system that would allow to
> manage
> > >> > the reservation by users of  various shared resources, such as
> > >> > rooms or misc. equipments. Simple and basic features are
> > >> > sufficient, just manage/check time slots to reserve, some resources
> > >> > and some users...
> >
> > >> > The application must be open source, written in Python,
> > >> > and possibly a web2py application (or else, Python scripts
> > >> > usable thru cgi or wsgi).
> >
> > >> > Thanks for your suggestoons
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to