webjay / asapp Goto Github PK

If any other page than #request is loaded first, the radio's are empty.

It seems the requests sometime show up in Monitor, sometimes they don't.

Some requests that are not showing up may appear later if enough refreshes. Some will finally appear, then disappear.

Not sure if you are aware of this/working on it.

Users can enable to receive a SMS when

• a new request is made
• only if the connection is dropped

Probably in red, or something similar. We should not waste a column to say "urgent"/"fyi", just color code it differently.

Maybe text color, maybe row background... Don't dwelve on it, keep it simple for now, and not too much "in your face/violent" eiyther, most requests will be of this kind,

It should stay at the bottom of the page, not always on the screen

Loading http://asapapp.herokuapp.com/ sends jQuery Mobile in a load loop.
Loading http://asapapp.herokuapp.com/index.html seems to work.

• Nodejitsu
• Heroku
• AWS Elastic Beanstalk
• Joyent

I know it will change, especially if you change the navigation (one vs several pages), but right now:

• if I click on "monitor", I get all the open requests. Good
• If someone else submits a new requests after that, and
• I click onhelp, then back on monitor, the only request showing up is the new one. The older ones I saw just before are not kept.

It may well be the right bnehavior if we assume we will implement client side cache of previous requests? Otherwise, it may mean we need to do the full request on the collection again, filtered by "non-closed" ones.

Thanks.

User can set which rooms to monitor and see by default when creating a request.

Ongoing process:
https://github.com/webjay/asapp#readme

need a better solution

Open the Messages app with prefilled text.

How is the application affected when we upgrade or downgrade services like Heroku, MongoDB etc.

When a user logs in and the user does not exist, create the user.

This is how I see the structure of version 1:

• Help: user can request for help
• Monitor: user can see requests, filter by rooms, problem types, status and see own requests
• Settings: user can define settings
  • Profile: user can set their role, name etc
  • Group: what is group settings for?
  • Room: Which rooms to see on the Monitor tab.

To simplify things further I would suggest we skip Settings for now, and focus on Help and Monitor. We need to get those two simple and intuitive.

If we skip settings, this is how I would solve the same problem:

• Which rooms to see help requests for can be set via a filter at the Monitor tab.
• Which rooms to get notifications from can also be set at the Monitor tab. I would like that the user can feel confident in the relevant context that they can see which notifications they would receive.

Why do we need to know a users role?

As for requests, the types of problems and rooms available can be set via the database. Later we should have an admin interface for easier management.

User can by radio set room, or by select other rooms.

Problems we need solved:

• send notification.
• make sure the device receives the notification even if it is in sleep mode.

We can send push notifications to Safari on OS X, but not on iOS.
Here is a demo for OS X Mavericks: https://kandutech.net

I found Pushover which we could use.

The safest would be to use SMS, meaning once an issue is reported, the backend will send a SMS to those who have asked for that kind of notifications, with a description and a link to the request. We could also offer replies via SMS.

In Safari it looks good, not in FF nor Chrome.

The problem is that the legend's are hidden.

What do you see @ghtca?
http://asapapp.herokuapp.com/#request

Sometimes they are listed twice, especially when I refresh, sometimes they are only once.

Like this:

I need help with:
AV
Recording
Mgt
mocha test
AV
Recording
Mgt
mocha test

related: #1

it works, but jQM goes flicker

We need this so it's easy to switch DB. One for production, one for tests.

Just add the text: "This feature is not implemented yet.", just below the second-level tabs.

Let's try to upgrade the text/forms to my original design, even if this does not work (subscribe to alerts with SMS checkckbox, etc) to help me explain the vision.

Also, since we';re in "Settings" top tab, we don't have to write "Profile settings" and "Location settings". I suggest: "Profile" and "Follow location" instead.

the second and third Help request have the same time recorded as the first one, even if I wait a few minutes. If i refresh "monitor", the wrong time still shows up, so it must recorded like this.

After I refresh the whole page, and I submit a new request, the new time is properly recorded.

We'll need to have a discussion about strategy/functionality here

or remove it entirely.

As we discussed, login can be handled in many ways.
Here's what I can think of:

• username + plassword
• username
• email + password
• email
• mobile + password
• mobile
• id

For simplicity I would suggest using just the users mobile phone number, as they remember that and we can send invites to them when you initiate a new project. Also we can use it for SMS in regards to #10.

Users can for a start be managed via the database. I'll update the documentation (#5).

Instead of "3/13/2014 9:26:18 AM", let's just display "09:26". It will help the UI a lot.

Still, let's make sure we sort properly on the full date including AM/PM, with the latest dated request on top.

BTW, priority (FYI vs Urgent) should not be used to sort. Only time. We should make Urgent request pop out with some color.

Happens on my phone and desktop Chrome, maybe other browsers:

• I login to exactly "http://asapapp.herokuapp.com", no issue
• I refresh the page. A strange white line shows up around the footer, still one footer though.
• If I go to monitor, now I have 2 footer on top of each other.

Thinking it's a sign of a bigger problem re: refreshing.

Could you please send me the file ds-logo-3.png

To keep it simple, I believe we have two options:

• Socket.IO
• Pusher

I would recommend Pusher as that will get us started fast and they have a free sandbox which should be enough while we build. The next level is $19/month.

Pusher seems to have a solution for most problems we can face, like checking if the connection is live.
Although we still need a solution for notifications (#10) if the device is in sleep mode.

Pusher have the Pusher Protocol which makes it possible for clients to communicate via Pusher instead of via the server, which would be more reliable. I need to investigate if the backend can also be part of the communication.

Let me know what you think @ghtca. I am also good with Socket.IO. One benefit with that is less middlemen.