Open Bug 778776 Opened 12 years ago Updated 6 years ago

Mozilla Events Mobile Web App

Categories

(Participation Infrastructure :: Events Manager, defect)

Product:
Participation Infrastructure
Component:
Events Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: kinger, Assigned: AlexLakatos)

References

(Depends on 2 open bugs,
URL
)

Details

So there have been some convocations floating around about creating a
mobile app for events such as mozcamp, mozfest, etc.... that will
quickly show the latest schedule on demand to attendees without having
to always rely on the wiki which is does the job, but not always in the
easiest or quickest way.

There are similar apps out there in the wild for other events such as
OSCON and FOSDEM so we know that these things can work and be useful.

The recommendations for this app, should it happen, so far have been
that it should be a webapp that can be installed from the marketplace,
and that it should be able to accept input for scheduling information
from a number of possible sources such as ical feeds, webcal, xml, json,
etc... to increase its reputability.

So...

a) Is this a good idea?
b) What features you would like to see?
c) Design ideas

There are a few community members already interested in working on
developing this, but if you would like to help out just
let us know!
Hi,
I'm ok when it comes to HTML, CSS and JS. I don't want to meddle on the server side, but if you need help with the client side mobile app, just point me to a repo.

Cheers,
Alex
I'd like to get the ball rolling on this as I think it is a great idea... so I did some rough wireframe/prototypes to help inspire some people. So I guess the first thing that needs to be known is what is the app going to run on... php/python/node?

I personally would love to see this on node... what do you think?

Proposed Wireframe/Prototype
* Home: http://cl.ly/image/1o020h1Y3e0W - this view also shows an example of in app notifications.
* Whats Next: http://cl.ly/image/132r3b0p0m3y
* Tracks: http://cl.ly/image/3S3e1Q3S1A08
* Session: http://cl.ly/image/3b2U2i2w2734

This wireframe/prototype works on the idea that you can change views using either the tabs or swiping side to side.

William (FuzzyFox)
Hardware: x86 → All
(In reply to William Duyck from comment #2)
> I'd like to get the ball rolling on this as I think it is a great idea... so
> I did some rough wireframe/prototypes to help inspire some people. So I
> guess the first thing that needs to be known is what is the app going to run
> on... php/python/node?
> 
> I personally would love to see this on node... what do you think?

We should first try to do a really simple prototype that just pulls data from the wiki. We can use the Semantic MediaWiki API (https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:SMWAskAPI) but that might mean a bit of re-jigging if the wiki to begin with.

Concurrently we can work more on design. Alex Lakatos said he knows someone with experience that would help with this.

> Proposed Wireframe/Prototype
> * Home: http://cl.ly/image/1o020h1Y3e0W - this view also shows an example of
> in app notifications.
> * Whats Next: http://cl.ly/image/132r3b0p0m3y
> * Tracks: http://cl.ly/image/3S3e1Q3S1A08
> * Session: http://cl.ly/image/3b2U2i2w2734
> 
> This wireframe/prototype works on the idea that you can change views using
> either the tabs or swiping side to side.

Excellent. Some great ideas here. The inclusion of tabzilla is a nice touch. I'd like to a see a home screen with the MozCamp logo (https://wiki.mozilla.org/File:Grow_mozcamp_logo.jpg) and some icons that lead into parts of the application (4 maximum).
    Based on a recommendation from Gerv, I think it makes some sense now we have a set of features that people would like to see in the app... is there something else out there that covers all these needs? and would work well with the systems we already use for scheduling (i.e. the wiki).
There probably is, but why shouldn't we build our own?
Well lanyard actually have a schedule tool built into their platform and it may be worth seeing if the features we would like that they don't have can be added. Might be a simple case of sending them an email.

I agree it would be nice to have our own, but is there a need when a tool already exists that has most of the features we need, and are willing to add the others?
(In reply to William Duyck from comment #6)
> Well lanyard actually have a schedule tool built into their platform and it
> may be worth seeing if the features we would like that they don't have can
> be added. Might be a simple case of sending them an email.
> 
> I agree it would be nice to have our own, but is there a need when a tool
> already exists that has most of the features we need, and are willing to add
> the others?

Ok feel free to contact others that have tools to see if they are open source.
Repository set up:

https://github.com/brianking/events-app

Alex, I am assigning to you initially to make a first pass. Are the mockups by FuzzyFox enough for you to go on?

As we are tight on time before MozCamp, let's focus on p1 and p2 issues identified on the etherpad.
Assignee: nobody → alex.lakatos
Alex seemed to say that he didn't "want to meddle on the server side". As it happens, I've sort-of started work on the server-side of the app, and I should have something usable within the next few days.

However, I am currently on holiday in Ireland, so don't be worried if you don't hear anything from me until after the weekend, as the place I'm staying has no Internet connection :(
So before diving head first... are we using the wiki api for this? as that is all the server needs to worry about mostly.
Well, my plan was to split up the app into multiple parts (kinda like the unix philosophy). So, the app takes stuff off the wiki using the api, parses it, and then dumps it in a couchdb database. Then the app will read from the db whenever it wants to display the schedule (or specific events) to a user.

This both cuts down on the number of requests to the api, and allows us to later add more services (such as lanyard?) to it.
I would then recommend that there is a regular scheduled event that checks the wiki hasn't been updated, and if so update the couchdb.
(In reply to Leo McArdle [:leo] from comment #11)
> Well, my plan was to split up the app into multiple parts
Awesome...

> This both cuts down on the number of requests to the api...
Well, one downside will be to set up a server polling at a regular interval, to fetch the new info from the wiki & update the DB.

This could cause in a latency, as the info will not be available in the app until the next polling occurs. Also, if we run the server polling very often (to defeat this caveat), it will fail its own purpose.

I don't (yet) have any better proposal though.
My personal opinion is that polling the server at a 5 minute interval at the server, over doing so from devices which will be staggered depending on when they are started, is always going to be better in reducing calls to the wiki.
I think we should make this a meta bug and open new bugs for the various parts:

- Design
- Server
- Client
- Anything else?

Thoughts?
(In reply to William Duyck from comment #14)

Not sure if a plausible idea, but if Wiki had a push-hook/plugin that sends a request (server-sent event, kind of) upon every actual edit/update on a certain page/subpage, to the DB server with the changed-content (or maybe DIFF), we could skip the polling.

It will be better than asking the wiki API for data every 5min & expecting a change, to actually receiving one when something has really changed.

Tomorrow I'll find if there is any such plugin - unless it's already found by then.


(In reply to Brian King (Briks) [:kinger] from comment #15)
> Thoughts?
Sounds good!
Depends on: 788186
Depends on: 790177
You need to log in before you can comment on or make changes to this bug.