Start and maintain a requirements/spec file

[lukeab]

What we trying to do here yo?

Can we write a basic statement of what this should do? list of features, maybe some graphics and story boarding would be nice.

[dominickm]

Yes, we should. I this I have a basic list done, but need to circle back with Chris Fisher before I can finalize it.

[ghost]

What about a simple game, or something that connects to other services such as a RSS news reader, or a client for social media websites? Perhaps we could create an app for Jupiter broadcasting, such as an IRC client that connects into JBLive.Tv. I know JBLive.Tv is an existing app. Perhaps we could do a new one or extend it.

[lukeab]

The existing android app i've seen does 3 things

• Play the live audio or video streams
  • Audio plays through a background process of some kind
  • Video plays in the native android video player, no in app
• view the rss feed, it's a bit a janky view though
• Donate button

I don't know what the ios app or apps out there are like, are there any already?

We can certainly try to match these features and implement them with a little more polish this time. I would also love to add the capability to download or watch on demand any show in the archive. I think there is an existing app on the android market for something silly like $0.99 (or £0.65) with a nice "Recent shows" view, showing all shows in a reverse cronological list. Additionally filterable by show, keyword searchable by title and description text or body decriptive text and meta data in the rss feeds or more complete or structured data from a webservice.

Push notifications for live show and show releases, selected optionally by the user by show and live/released status. I'm not sure how easy push is when using phonegap as the basis. Maybe it's no problem, but i'm not the expert.

Some kind of community features. perhaps a way to view or monitor forum threads? Or some kind of alert from the irc chats, or an irc chat window? maybe that's over kill :)

Anyway, brainstorm away folks.

[dominickm]

A lot of good ideas here so far. One suggestion: I think for the v1 we should keep it as minimal as possible, so we don't bite of more than we can chew. We can always add features later.

Keep the ideas rolling in, though!

[ghost]

Here's an idea. I was thinking about how I find it hard to remember when the JB shows are on. The JB shows are in a different time zone from me and I just forget. So it would be really cool if we created an app that acted like an alarm system or a reminder system. You could choose which shows you like, if you are interested in the live or recorded streams, and it will come up in your time zone. The app will remind you when shows are coming up.

The great thing about this idea is that it will teach people how to get information from external sources, use offline storage, work with date and times, compare text, work with DOM, display in HTML5, and get input form the user. Some of which is what I wish to learn how to put into practice and it is not too difficult to learn. I would like to use JSON instead XML for storing your preferences but both are just as good. Since RSS is XML then it is likely that we could just store the RSS XML in offline storage.

[lukeab]

hi there Daniel, Absolutely, that's definately a brilliant idea. That's what I was driving at when i mentioned push notification for for live shows and show releases, I think you are right, the options to select which shows to be alerted too could be a pretty central function of the app, coupled with the connecting method to view or listen to the stream or downloaded files directly from that alert.

I would however recomend we concentrate on the functionality of the app and work with external services to synchronise times, such as google calendar. It is a very good point, and I am in the same boat as you, that many peoples time zone differs, i'm in London living in BST right now, which means PST on jupiter broadcasting is pretty useless and confusing for me too.

However if you use the google calendar link on the calendar page on JB.com, you'll notice it converts the time automatically.

Looking at the url from the calnedar page, it delivers location information along with the item, which google must use to derive the time offset.

https://www.google.com/calendar/event?action=TEMPLATE&hl=en_GB&text=LIVE%3A%20Coder%20Radio&dates=20120702T090000%2F20120702T100000&location=http%3A%2F%2Fjblive.tv&ctz=America%2FLos_Angeles&details

which decodes to

https://www.google.com/calendar/event?action=TEMPLATE&hl=en_GB&text=LIVE: Coder Radio&dates=20120702T090000/20120702T100000&location=http://jblive.tv&ctz=America/Los_Angeles&details

From this we can see the show title, start and finish times of the entry, and a ctz=country/city item, from this the event has a timezone based on that ctz info, and google's api can do all the math for us :)

It is good to be aware of these items of info in general of course, so when it comes to other features handling more information, perhaps forum entries etc. we may still have to deal with time zones.

[ghost]

@lukeab what do you mean by the functionality? Don't we need a to have an idea first before we take it further? Is it dominickm who decides what the app will do? I noticed that a design document is being drafted but it seems to me like we are rushing a head a little. Do you mean functionality as in the functional and non functional requirements? As an amateur developer I am not sure where we are in this process?

Has someone already decided what the main features are?

[dominickm]

@Techfix So there has been a few discusion regarding functionality and we know we will have a few things for sure. JBLive integration and podcast style subscription for video and audio. Really these features would probably be the core functionality of the app; given JB's business model etc.

There a few things that have been mentioned but not discussed fully: including IRC chat, social integration (Twitter etc), and notifications.

My has been that we should get the player functionality down first, then worry about adding other features in a point release. However, that doesn't mean that we shouldn't actively discus the design and additional functionality in parallel.

Let me know what you all think.

[ograycode]

With regards to push notifications, I didn't see any PhoneGap plugins that supported this, besides Urban Airship. I believe they are very expensive for what they offer (10,000 users for $200 a month). That said, we could always write a plugin for PhoneGap, http://wiki.phonegap.com/w/page/36752779/PhoneGap%20Plugins. At least Android 2.2+ supports the push notifications use GCM, http://developer.android.com/guide/google/gcm/index.html. I don't know if iOS does to, but I would be very surprised if they didn't have a similar service.

GCM PhoneGap plugin on GitHub: https://github.com/marknutter/GCM-Cordova I haven't checked it out, but may be promising.

[daviesm]

@dominickm I would like to see an IRC chat included, especially for the podcasts. It is such a central part of the shows, that it would be a mistake to not include it (at some point).

[lukeab]

That's a nice idea, the chat feedback can definately be a great addition to the experience. I always have an irrsi split on my screen session during the show. I do think it's a hefty proposition though.

There are more live feedback elements to the shows that get brought in than just irc, google+, facebook, reddit and twitter are often reffered to on air. As a "backlog" idea we could look at having a tab or tabs to aggregate all the relevant data for any given show :) It might just be all a bit ambitious though.

I am trying to imagine how it would be implemented in the UI, small screens like that wouldn't lend themselves to viewing both video and irc in one view, audio might lend itself better to it, but you'd always need to be able to turn it off, to conserve bandwidth if you are purely on a mobile network or something.

I think the live show views could have some kind of read out or tab of the chat, but i'm not sure posting to irc from mobile is very effective or easy, perhaps read-only would be nice, and simpler to develop.

I would argue 2 reasons to avoid it certainly initially:

1. using irc on mobile, for input it's slow and so not a very real time friendly platform
2. hard to implement, especially for a new project and group of developers.

As you said @daviesm for v1, KISS

But i'm all for maintaining a backlog :)

[dominickm]

Hey guys,

The IRC thing is a great idea, but it feels like a v2 type of thing, since there are a number of challenges presented by it some of which @lukeab mentioned. I also feel that IRC chat would be more effective on a large screen.

[dominickm]

@hothead2 I don't think push notifications will be in the V1, since that could potentially cost the network money and I don't think we have a budget ;). Also, how old is that plugin?

[lukeab]

One alternative for push notifications is to route everything through something like the google calendar api, (do apple have an alternative??) they'll get appointment alerts as long as the user has calendar syncing on their phone, which,, lets face it, who doesn't :)

[dominickm]

@lukeab Apple does have some iCal stuff via iCloud. However, I don't think we can do that with PG and let's be honest A LOT of people who would use this app would also be GMAIL / GCAL users, so I think that is a pretty good way to go, as you suggest.

[ograycode]

Going off the google calendar / ical, instead we could just pull Jupiter's calendar periodically (like once a day) and store it in a db and set alarm notifications.

Workflow would be something like: See if user has notifications enabled -> call Jupiter's google calendar -> Store in db -> Set alarm for first notification time -> alarm goes off -> notification displayed -> app checks for next date time in db -> set alarm -> alarm goes off -> notification displayed -> app checks for next date time in db -> etc.

The calendar looks very standardized, so it would be fairly easy to parse for specific shows and add new ones as they are added.

This way we aren't dependent upon a third-party application to handle the notifications.

EDIT Here is a link to google calendar rest api to play with: https://developers.google.com/apis-explorer/#s/calendar/v3/calendar.events.list?calendarId=jalb5frk4cunnaedbfemuqbhv4%2540group.calendar.google.com&timeMax=2012-07-31T19%253A27%253A05%252B0000&timeMin=2012-07-01T19%253A27%253A05%252B0000&_h=1&

[ghost]

So if the main purpose of the app is to play the live or recorded streams from JB live. We essentially need to decide on how exactly it app going to do that. With the live streams, we are probably better off going with HTTP Live Streaming(HSL). There are already a whole bunch of players that support android and iOS; plus it looks like we the phonegap will support it(http://docs.phonegap.com/en/1.9.0/cordova_media_media.md.html#media.play).

if you notice playAudio("http://audio.ibeat.org/content/p1rj1s/p1rj1s_-_rockGuitar.mp3"); JBLive streams via hls as a mp3 format anyway. phonegap supports access via http.

I think it would be prudent for the app to check if the mobile is connected to a wireless network or not before streaming, and to warn to user that they are using 4G/3G/GSM with a "do no show me this again" option. Alternatively the application settings could have an option of what type of internet connection should stream the video/audio.

Mobile internet can be costly, but WiFi is often free or cheap and Mobile Broadband is often quite slow. It terms of the UX, it is likly that the first screen will be like the JB website with options to donate, watch live or watch a recorded show.

The video will no doubt need to take up most of the viewing area. Other features such as IRC could be over-layed on top of it, like semitransparent layer, or they will be on different screens while the streams are playing. The audio may not need to take up the entire screen.

Functionality:

• Check the network connnection
• Store settings offline
• Warn the user if an action may cost them money
• Play audio from http://jbradio.out.airtime.pro:8000/jbradio_a (128K) or http://jbradio.out.airtime.pro:8000/jbradio_b (64k).
• Play HLS video steam from http://videocdn-us.geocdn.scaleengine.net/jblive-iphone/live/jblive.stream/playlist.m3u8
• Play recorded streams via the rss feeds.
• Display the videos available in a interesting way.

A prototype is needed for testing. I have an android phone (HTC Desire). So I could create a test app to see if it would work. What do you think?

[lukeab]

@hothead2 yup, however no need for local db code for the schedules in our app, as we can create alarms just by setting them in calendar through the api, rather than having our app instantiate alarms on the phone itself, as their google calendar will by sync'd and locally stored and fire alarms by the existing calendar functionality built into the phone.

Local storage can store the selection of shows the user is interested in so the app knows what items to insert into thier calendar. The interesting bit will be gaining authentication for users calendar services across android and iphone, maybe this is something phonegap does seamlessly though. i don't know :)

[ograycode]

@lukeab My only concern with that is becoming dependent upon another application, which may or may not be installed on the phone. Perhaps the user uninstalled it for whatever reason? May be google/apple will change the api or even completely remove the api? At least on the android side, it appears to be an undocumented, and we shouldn't be using undocumented content providers like this ( http://android-developers.blogspot.com/2010/05/be-careful-with-content-providers.html ). Further, I just don't like to make assumptions about the user's device.

However, ultimately, I don't think it is my decision on which route we go.

May be we should start breaking down the issues further? Like a notification issue, playback issue, live issue, irc issue, etc. Perhaps a wiki page can be created with checklist style requirements for release 1, 1.1, etc?

[ghost]

I agree with @hothead2 regarding using a external services to provide something that is the core functionality. It's really temping to do this, since all the hard work is already done for you. However, what is the alternative? As Chris Les has mentioned on countless occasions on JB, all of his work is done on google apps. So it make sense to use google calendar as @lukeab suggested. We can't guarantee that Chris Les Will continue to use google in the future. This is perhaps one of the benefits of open source, that is, when something changes, the community can update it as needed. Maybe we don't need to worry about it as much.

Just a thought... The phone gap provides an interface for the notification system on android, blackberry, windows phone 7 and the iPhone. This could be used as our so called reminder/alarm system. Times zones problem is a matter of simple addition or subtraction to/from universal time(or GMT). It may not be too hard to implement.

I am not sure if we should start with the IRC feature initially since that is an application in its own right. It seems clear that we want the app:

• To play streaming video and audio content from Jupiter Broadcasting live and recorded.
• To browse through the broadcasting schedule(s).
• To notify the user of up and coming shows.
• To allow the user to chat via the IRC system on Jupiter Broadcasting.

I propose that we start to put pen to paper and hopefully we can really break this problem down into finer details.

So here is my questions are what should be in first release? What is the most important part of the app? What can we live without in the first release?

[lukeab]

If phone gap offers implementation of setting alarms across all relevant platforms, then maybe this is a nicer approach. If we try to implement the calendar support instead then sure enough the risk of a 3rd party service is going to be a pain, and while google's reliability is definately a higher dependability than most, it still is a concern.

The one advantage of using calendar is that this then becomes set everywhere, on your browser if you have calendar open, in your desktop email client if you sync with google calendar, any other devices you own that connect to gcal.. etc etc.

If we implement the calendaring feature using a service oriented approach, this should make the mapping pretty plugable, and the community cna write new calendar modules as needed. perhaps even if the local alarm notification followed the same approach, multiple calendar providers can even be triggered, or cascade to prefered service in case of failure.

Well i'm getting into a service injection pattern implementation discussion here witch is more suitable after the initial spec is complete.

On the time zones, it's a little annoying, the timezone information is not in PST or GMT or offset +0800 format, it is provided only by ctz=America/Los_Ageles so we have to know we can map locations to offsets, then yes, simple math solves the problem for us. Again google calendar api has this feature built in it seems, as when you click on the link and it brings you to the calendar page, it finds the offset for you, though i'm strugling to find mention of determining offset from location identifier in the google api docs.

@Techfix one additional point that @dominickm brought up was what to do with a homepage. His suggestion was to have a twitter feed from JB at the strat to have data, but 2 things, 1. Again the 3rd party service dependancy and 2. This isn't the core of the app, so far the core seems to be the upcoming, live and archive of aired material on JB. This would represent the focus of the home page more purposfully to me.

I was thining a banded approach lending itself to scrolling on a mobile device.

1. At the top, what the next scheduled live thing coming up is also.
2. Next the status of the live stream is (what show is playing, pre-recorded or not)
3. Then the majority of the page down lower, the latest archives of shows downloaded/streamable in video or audio, limited to going back a week or 2 for sanity.

The design of JB's own homepage provides a similar layout as to what i imagine in point 3, but with the schedule calendar laid out at the header instead of in the side bar as it is on their homepage, also with a little more polish :)

Perhaps for the microblog aspect of JB's activity, a seperate Social view aggregating all the outputs would be nice, starting with twitter and if we can g+ too.

[ghost]

The 3rd Party Issue

@lukeab - The most I have done with the Google API is add a G+ onto a website, so I feel that I don't have enough knowledge on the API to mention it. I have played around with android development kit in eclipse since I have had an android phone, but I have never done anything really serious with it.

I also would like to say that I am not completely against the idea of 3rd party sources. After all I did suggest it in my first post. What my real concern is that we have to take our target audience into account. I'm guessing that you - @lukeab - are an android user like myself. If you use android then you will have a Google account, it's mandatory for the Google play (aka the android market). iPhone users are not required to have a Google account, instead its an Apple/iTunes account.

Not everyone uses Google. I know...terrible right? The same applies for all the other services e.g. Twitter, Facebook, LinkedIn, Live etc...

I am of course; a user too. The one thing I hate (beside badly made Java applications) is when an application tries pigeon holing me into a service, which is why I like open id's. I can understand your wish to pursue the Google route, it is a good path to go with. If anything I share the same wish.

May I mention that - at least in my view - the application subscribes to the XML feeds on Jupiter Broadcasting Website. Would it be possible for @dominickm to ask Chris Les if we could manage all the shows this way and perhaps provide a way for the app to request a list from http://www.jupiterbroadcasting.com/ directly. The URL could be the same, which spits out the information from any source. The reason I prefer XML is because JavaScript can parse it quite well, plus it is the universal way to communicate structured data accross API's, networks and applications. As the application evolves, the way it gets information stays the same, making it a little more future proofed.

Google Calendar Supports XML feeds instead of RSS which would be more ideal. That we there is no Google API to worry about it's all JavaScript. For example we could just to an http query to: https://www.google.com/calendar/feeds/ajia36of2jk1cq31g2csg3qpqo%40group.calendar.google.com/public/basic and get the XML back. (This is a real calendar I made as an example so please no spam) the result can tell you all the information you need from the timezone to dates and times. if JB could do this and provide the XML from there website then that would ideal.

I believe that the application should be able to run off of different sources that way if one is not working then the application can simply switch to an other 3rd party. It really should be up to the user to choose the different sources they prefer. This all depends on what information we get from a service.

I would prefer if the notification logic was local and inside our application. Not only will it be a challenging learning experience but it will make our application more reliable and, as it may reduce the need to connected to the internet all the time plus this would provide a consistent UX.

I know you said that the schedules should not be stored locally, but I do not share your view. Having an offline copy is a good idea, for example I know that most of the time my mobile/cell phone is offline to save on battery life.

The homepage issue

I am not keen on using the twitter feed as it provides very limited information. I suppose that limited information = less network bandwidth. So that is good. I like @lukeab idea.

My vision of the UX is something like the google play app. where you have a tabbed/paged navigation system. Each tab/page could be a different way to view the schedule. It could have carousels, sliders, grid and list views. Some slick animations would be nice, since that is a major feature of HTML5 and CSS 3. View Ideas:

• Series View - where you can choose a show like coder radio and it displays all the episodes from that show
• Latest - chronological list of episodes
• Contact View
• Support JB

I think all the shows showed be displayed in chronological order.

Idea for of a list item:

Thumbnail | Show title [Watch] [Remind Me]
Description and info

when you press watch it brings up a list activity: HD Video, Standard Video, HD Audio, Standard Audio. Remind me should bring up the remind me system.

Something like this would be ideal. If we went with my XML idea via JB then this would be possible. Otherwise there would be some trade off between what we could actually get from a third party.

In additional

We really need to know where the information is coming from, and what is included inside the information.

[ghost]

I've just realised that phonegap media only supports audio. So we may need to look for an alternative.

[dominickm]

Great conversation folks. I'd just like to interject with a few things, so we can get moving :).

1. Let's forget about 3rd party calendars for now and just use the PG implementation.
2. I don't think that the should have the Twitter feed as the first view of the app but rather a list view of all the shows that tapping on would allow the user to either subscribe or listen to / view. Sorry if I caused some confusion there.
3. PG does not provide support for video, so we are going to have to roll our own. I have some ideas on that but will report back when I have come up with a solution that I think would work best.
4. As for XML I don't think that we have a choice -- ie I am pretty sure that XML is the only option but I've emailed Chris regarding it to get a backend spec; worse case we just use the feeds. When I have a proper backend spec together, I am going to post it to the WIKI.

Thanks for all of your input and I will be pressing hard this week to get these questions settled. Keep up the great work!

[lukeab]

Fantastic when a plan gets crystalised into blocks and bullet points.

I'm going to make a controversial suggestion at this point and promote the start of some basic view wireframing and story boarding? Are we ready, or do folks feel being exposed to one "designers" view point will railroad them into a fixed app design too early?

\ p.s I am not a designer, no way no how, but i'll do wireframes with my null artistic ability :)

[ghost]

@lukeab I am half artist half technical geek. So I can help with the UX. I have already created a test app for the android side. I managed to get it to play the live audio stream. It's not on git hub yet, since I would like to follow the development process properly, so that we do not rush ahead too much. I am looking into building m3u support, or perhaps extending the phonegap software - if possible - which would allow us to have video.

I was considering how I use my phone... I am not convinced that many users would benefit from the streaming videos. I tend to just listen on my phone, rather than watch. I think that we should have short development cycles where releases are miniature updates. That way we can concentrate on each feature and give it the attention it really deserves. I'm hoping this will result in a really well made app. I think for the first release and just implement the UX, the audio playback and the reminder system. What does everyone think about this?

I am not too familiar with git hub. Is it possible to share images perhaps via the Wiki or something? I could post some UX ideas. I should point out that this issue is requirements. Perhaps we should talk about the design on the other issues post title "design UX Discussion".

I not sure if storyboarding is the way to go, and I don't know what you mean by wire frame - that is a term used in 3D graphics, so its confusing me. What about a flow chart with a story board quality to it. Kind of like those visual studio adverts.

Storyboarding tends to have a start, a end and then run in a sequential order, but the apps navigation may not be sequential. Something like a sitemap design would be good. Which is like a story board as each page design can be drawn out plus it also shows the navigation and information flow.

I don't know if that is what you mean by storyboarding? Either way I am happy that we are getting somewhere :D Hooray for JB!!!

[lukeab]

Yes I agree, story boards are generally linear, so Application story boarding is part flow diagram and part story board, I've often though a nice flow chart/story board app that could show you a linear story board based on a selected flow from the over all chart would be awsome. We do it in work by printing and posting our webapps' wireframe page layouts on the wall with bluetac, and connecting buttons on the pages to other pages with string. Kind of rediculous but the amount of times it's helped us spot a hole in a user story is amazing.

Wireframing is just a simplistic outline for how the apps layout would sit to satisfy designing functionality. I've always quite liked the look of http://www.balsamiq.com/ wireframes, and i'm just looking through https://gomockingbird.com/ to see if that's any good since it's a bit cheeper. A nice free app we can all contribute with would be nice though. Of course we can always just use inkscape or gimp :)

Actually one i saw a while ago has just come back to me, http://pencil.evolus.vn/en-US/Home.aspx free firefox plugin. nice.

Anyway, on the streaming, maybe your right, I find myself looking at youtube video quite a bit these days on the phone, in bed or other places around you home your immobile for a while :P So viewing the archived video is probably the most practical and useful feature. I also watch pre-downloaded video while on long commutes and things, the London tube is painfully slow sometimes.

The live stream i think is something new and exiting though, so I feel like it would be fun to include. Being a "progressive Real Time mobile application" would be such a nice feature in the communities cap :)

[dominickm]

@lukeab I'm glad you like my list. I do thing some basic UX spec would be a good thing to get together, even if it ends up getting super-ceded.

@Techfix Any chance I could see what you had in mind? You can just email me screen shots if you are more comfortable with that. As I said before, I think we have our 4 points for basic functionality and some sort of rough UX doc would be helpful.

I use Balsamiq, but I don't want anyone to have to buy anything to be involved, so let's find a different tool.

Keep it up!. I am going to try to actually push Chris for those docs this weekend.

[ghost]

@dominickm You asked me to send you an email regarding my test app... I don't know your email address. So I created a video to show you on g+. You can also see my video on youtube: http://youtu.be/-sSDdgtmuZQ

Enjoy!!!

[dominickm]

@Techfix Great thanks. Sorry for the email thing. I thought there was one displayed on my GitHub account.

I'm taking a look at the video now.

[ghost]

:) Feel free to comment about my video.

[dominickm]

@Techfix I just commented on the G+ feed very good. You mentioned a second version in the works. Let's share that one with the rest of the group. I think you are on a a good track.

[ghost]

OK well I will have it on git by 0.00 GMT (17.00 PST). :)

[ghost]

@dominickm I'm really sorry. I did commit my code up on Sunday and tried to merge it but between commenting issues and the UI stuff is being decided - So I removed it. I haven't given up. I am sorting out my fork right now. I worked out the commenting issues and which are now fixed on my windows computer. I am working on the SRS Wiki Page. Since the play feature of phone gap I did is basically copied and pasted (well sort of), with some better JSLint Formatting...lol :P. I think I will just ditch the UI and CSS stuff for now, but keep in the JavaScript/phone gap stuff. I will have it up tomorrow (11th July) with all the comments done right. Don't panic I have plenty of backups :) and I copy of the different versions I have created. The version on the video was actually the third version not the first. Once the design has been shelled out a little more then I will commit the UI stuff up using whatever library we have decided on. If you still want me to commit everything, please let me know.

@everyone I had an other idea. Phone can check the type of network connection the device is using. So why not have our application auto decide on which stream to use eg. am/fm ... sd/hd. Just a thought.

[dominickm]

@Techfix no need to be so worried. I'm sure you'll sort it out.

I'm not sure I understand what you mean in your second paragraph. For the phones having the high def stream may not be worthwhile. Any other thoughts on that? Am I just confused here?

[aaboagye]

@dominickm Correct me if I'm wrong, I suppose that he's proposing that given the connection that the user has, deliver the appropriate stream for that bandwidth.

ie: If the user is on a 3G connection, deliver the am stream or the standard definition stream. Or if the user is connected to wifi/4G, deliver the higher bitrate streams.

[dominickm]

@aaboagye Ah that makes more sense ok. Yeah, I think it should still be a user choice, regardless of network. But that is a clever idea.

[aaboagye]

@dominickm Yeah, I agree with you as well. Some users may have a slow wifi connection or something. But I think it would be best to not assume what kind of stream the user desires, and just give that choice to the user.

EDIT: spelling

[ghost]

I supposed it doesn't matter...I personally can't run the app on a mobile broadband network because no 3G in my area. 3G is up to 0.2Mb/s, where as wireless is as low as 0.5Mbs/s and up to 150Mbs (depending on the country). The difference in quality is noticeable in some broadcasts.

@dominickm I am also thinking of the future of this application, If we add video support later, then this will be more important. I still think the application should check the connection settings. In the preferences/settings "tab" in our application I would like to see a option where the application will warn you if you are using a non-wifi network. Your hear so many horror stories about how users get big bills for bandwidth usage. It depends on where you live I guess and the company you go with.

I also wanted to bring the idea of translation and documentation. Is what languages is this app going to be in?

[dominickm]

@Techfix It would make sense for the app to be in English, as all the programming is currently exclusively in English.

[ghost]

Will the app use a playlist? I thought I would be cool if you could queue up different shows.

[ograycode]

I think it may be a good idea to add logging to our application. It wouldn't be that hard to roll our own logging into the database. Plus, it could help with user issues, bug reports, general analytics, etc.

[aaboagye]

I second this idea.

On Sun, Jul 29, 2012 at 8:21 PM, hothead2 < reply@reply.github.com

wrote:

I think it may be a good idea to add logging to our application. It wouldn't be that hard to roll our own logging into the database. Plus, it could help with user issues, bug reports, general analytics, etc.

---

Reply to this email directly or view it on GitHub:

https://github.com/dominickm/jupiter_broadcasting_mobile_community/issues/3#issuecomment-7359499

Aseda Gyeke Aboagye

[ograycode]

I went ahead and started one because I couldn't find any: https://github.com/ograycode/Cordova-Logger

I don't know yet if it works, but the idea is to make it as simple as possible; change a few variables and you should be good to go. I imagine usage to be as simple as: logger.log("Hello World", logger.log_level.INFO);

[ghost]

I third that idea! :D

[ghost]

I would like to suggest that the IRC should be on a separate ui page which you can access via the footer links. Perhaps it should be completely separated from the audio and video feed since it may enable users to treat it like a chat room. I think the UX for the IRC should resemble the SMS application on a smart phone.

What do you think?