What are the immediate pain points with Dahlia?

1 view
Skip to first unread message

Justin Bozonier

unread,
May 4, 2011, 7:39:48 PM5/4/11
to HarmonyHacks
Has anyone started using this yet? If so, what is the thing that hurts
the most? I know we've already talked a little bit but I'd like to
move the conversation to a more public forum.

Victrinia Ridgeway

unread,
May 4, 2011, 8:45:55 PM5/4/11
to harmon...@googlegroups.com

I am using it.... And will respond to this tonight.

Justin Bozonier

unread,
May 4, 2011, 8:46:26 PM5/4/11
to harmon...@googlegroups.com
Hawt! SAWCE. :D

Nicole Wise

unread,
May 4, 2011, 11:43:35 PM5/4/11
to harmon...@googlegroups.com
I've been using it. I'll response bright and early in the morning :) 

Nicole Chablis "Nikki"

unread,
May 5, 2011, 11:15:54 AM5/5/11
to HarmonyHacks
From a User’s perspective it works well! The only headache I have had
is trying to figure out how to wait list a patient. I know it's
possible as I see others have been able to create a wait list; I just
am unable to find that option intuitively.

:S Nikki

On May 4, 5:45 pm, Victrinia Ridgeway <theladysab...@gmail.com> wrote:
> I am using it.... And will respond to this tonight.
> On May 4, 2011 4:39 PM, "Justin Bozonier" <darkxant...@gmail.com> wrote:
>
>
>
>
>
> > Has anyone started using this yet? If so, what is the thing that hurts
> > the most? I know we've already talked a little bit but I'd like to
> > move the conversation to a more public forum.- Hide quoted text -
>
> - Show quoted text -

Eric Ridgeway

unread,
May 5, 2011, 11:21:25 AM5/5/11
to harmon...@googlegroups.com

To waitlist a participant dont assign them a bedcode... This works around my wifes work flow

Justin Bozonier

unread,
May 5, 2011, 11:44:23 AM5/5/11
to harmon...@googlegroups.com
Thanks for that feedback Nikki! 

It's awesome to hear the positive and I hope to hear more criticism as well. The app could be so much better in a myriad of ways. If we point out flaws that hurt one of our egos... Then it's an awesome growth experience for that hurt ego! ;)

Thanks again.

Nicole Wise

unread,
May 5, 2011, 1:49:24 PM5/5/11
to harmon...@googlegroups.com
Ah! Thank you :)

On Thu, May 5, 2011 at 8:21 AM, Eric Ridgeway <ang3...@gmail.com> wrote:

Eric Lee

unread,
May 5, 2011, 6:46:26 PM5/5/11
to harmon...@googlegroups.com

So, as a dev one of my main pain points is still dealing with the database file.  I see that we have the .mdf file checked in now.  Was that intentional?  It’s usually modified whenever I run on my local machine so it’s always ends up in my commits, and I don’t think other people want to sync to my random test data.  Of course not having it checked in is also a pain because then a new dev has to know to create the database file first before running the app.  What’s the best practice here?

 

Eric

Justin Bozonier

unread,
May 6, 2011, 11:48:29 AM5/6/11
to harmon...@googlegroups.com
This is actually a good point as a feature... This isn't a very intuitive way of waitlisting someone. At some point it may make sense to provide a more direct method.

Thanks Nikki!

On Thu, May 5, 2011 at 8:21 AM, Eric Ridgeway <ang3...@gmail.com> wrote:

Eric Ridgeway

unread,
May 6, 2011, 12:14:01 PM5/6/11
to harmon...@googlegroups.com

Agreed ... I remember us(harmony hackers).choosing this pattern early on based on trying.to get something working. However its def time to make that option easier to identify to give us more coverage over a wider group of potential users.

Justin Bozonier

unread,
May 6, 2011, 12:16:26 PM5/6/11
to harmon...@googlegroups.com
Yeah... we're definitely still that mode so yeah it isn't a high priority to me. Unless Victrinia says otherwise I'm cool with waiting on that until after she's happier with the app. 

Victrinia Ridgeway

unread,
May 7, 2011, 12:31:44 PM5/7/11
to harmon...@googlegroups.com
I think the wait listing feature being resolved better will have to be addressed when we get into the editing mode for the participants. Without that feature the point of the manager is lost, because the intent isn't to create multiple instances of a participant across all retreats, but rather to have an interface to manage a single user instance across all available retreats. 

So far what I have been able to do in the live environment is:

Create and delete retreats
Create participants within their primary retreats
Search for participants

What I have not been able to do is:

Delete participants
Assign participants to more than one retreat within a single profile
Edit participant information, room assignment, assigned retreats
Generate a report for a retreat

Major problem in process of being addressed (within the AppHarbor enviornment):

Available rooms now are removed from availability as they are assigned to a participant.
         Bug: Room availability is not defined by unique retreat date. Rooms are unavailable across all retreats once it has been assigned within one retreat.


Once these things are all functional there are a few things which would be ideal to have:

1) Room assignments should appear in the same order as they do in the selection list. This is actually very important as it leads to decisions around organizing the participants into their groups, as that is determined a lot by room location. So I might find myself in a situation where I need to change a room assignment based on which grouping is most appropriate. If I have them in the logic flow of their buildings (which you were done in order of their relative location on the campus) then it is easier to make sure I am matching participants to the group which will provide them the deepest possible experience.

For example, if I have several mom's with breast cancer and they have kids, I will group them together in a building so they can be in the same group together. 

2) Spacing between each participant profile so that it is easier to read.

3) To expand functionality into all areas of the organization (Wellness Retreats, Rentals, Cancer Retreats) having categories of retreat types would be awesome. Could this be resolved with maybe having multiple instances of Dahlia running??

Within that expanded functionality, we would need to add the beds which were not initially added when we were thinking strictly of cancer retreats. But in all honesty we created the bed list based on a static model of how it's done now... but it's clear that will become a significant liability to future expandability of the campus and program configuration changes.

Ideally having a UI to modify the bed list in the future would be hawt... but I think we could just ask our dev friends to add on to that as the years go by for the time being. It's not an immediate need, but really it's a bow on the gift.




I hope this all makes sense.... Thanks!!!!

Victrinia

Victrinia Ridgeway

unread,
May 7, 2011, 12:46:32 PM5/7/11
to harmon...@googlegroups.com
Further point of clarification.... "Room assignments should appear in the same order as they do in the selection list."

At this point the participants appear in the list in order entered. However the view should reflect the same order as the room assignment list... While we based the application on the physical ability of the cancer participants relative to the bed location most appropriate for them. The bed list also provides a reference to group people near their small group session locations to keep them as close as possible to the group most appropriate for them.

For example almost everyone in Creekside (CS) will likely be in the same group... etc.

Let me know if people need any more clarification around anything. Thanks!

Victrinia
Reply all
Reply to author
Forward
0 new messages