Design / UX Discussion needs to take place

[dominickm]

As we get things together for the project, I think it would be a good idea to start the discussion surrounding UX / design earlier rather than later.

Let's try to brainstorm UX ideas here after we have a basic feature set down, so we can all be on the same page in terms of functionality and the UI.

[lukeab]

some questions and kindling for further discussion here.

Screen resolutions

First question, since we are looking at bundling a web app into a packaged mobile app, do we design for mobile but have a progressive or responsive design approach allowing for other form factors, or should we reign in our focus and stick to the iphone/android standard screen widths.

On that constraint, most data shared by good web type folks indicates that the 240px width is the standard minimum width of mobile web users, with maybe 0.3% using less. In terms of devices we're targeting, we can sfely assume 340px as a width for any ios or android devices. Can we safely assume this higher value as the minimum, or are there other platforms we should be wary of.

Tablet devices

At what point if at all do we consider the larger form factor?

Interaction support

Based on an activity what level of interactions do we allow support for in the app beyond just tap events, will there be needs for draggable elements like multi selects in two columns, or volume sliders. Should we turn to a generalised library to support the event types that are possible like jqm, jqtouch or fidget. i don't know many libraries myself so other suggestions would probably be more informed.

Theme

I would say lets keep multiple themes off the table for now for simplicities sake, but then we want a nice theme as the main design goal. Keep the design brighter rather than veering into dark shades and emo'ness. Though some kind of standout quirky quality to the app would be nice, being that this is jupiter broadcasting related and not just a generic businessy app.

Concept design

In terms of a guide to composing views, i found a resource i think looks pretty great. http://mobile-patterns.com/ The examples on this page should help inspire us in create a well focused activity oriented views in our app.

that's it for now, back to my day job.

[dominickm]

@lukeab you bring up a lot of good points here and I am going to take some more time to think about some of them before weighing in on them.

However, right of the bat I think we should design for the standard iOS / Android screen resolutions and take tablets off of the table.

My concern is that a lot of open-source projects that get to ambitious fail and would hate to see that happen here.

Any other thoughts?

[davidcornu]

Do we know what features the app will have yet?

[lukeab]

Hooray i'm useful: http://www.youtube.com/watch?v=le6Rvy5Ccb0

Yes I agree, as I figured keep the scope under control to limit scope creep. At this point, like david points out, we should wait till the spec is at least delivered in draft form before we focus on more UX concerns, as we will need to know what the app will do before we can determine what UX concepts will impact the project.

Till then, adéu.

[dominickm]

True true. Truth be told you all jumped on this doc a lot faster than I thought you would. Anyway it's good we have it here either way.

[odysseywestra]

I have been doing some research on the design guidelines for iOS and Android. I'll post a few up in a couple of days once I get my thought straighten out and drawing out on my Laptop. I've only know the basic on python, bash and worked on a game with the RenPy' SDK, so I not so good at programming, but I do love to design stuff. I''l come up with designs that will feel natural with both platforms just give a me a couple of days.^^

With functionality of the app I think it should just start like what the previous developer did on his design. A basic search and execution type app. Where it would search the rss feeds of JB and pass on the video and/or audio player of the user's preference and build upon that. You said that we should not get to ambitious cause that my lead to it dying out so let start simple and build upon it.

[archblob]

What library will be used on the UI front so that it will look as native as it can be considering it is not :-P ? JQuery Mobile, Sencha Touch, XUI, or something else ?

[lukeab]

JQM and JQTouch are more style and layout aids than much else, they abstract a little of the event's model which is helpful too, but many people consider them heavy and even harmful as they limit the developer, they end up railroading the coder into following certain design patterns that are all too common. Sencha touch i've not had a chance to look at yet.

I would hope we could avoid too much framework use, when we also have the phone gap aspect to work with, i'm not certain how much of a layout or interaction abstraction it gives us, as i've not played around with it yet.

But in the interest of constraining ourselves into code patterns we can all follow, with a framework teams work better.

In that direction, zepto does trade on it's lightness, again between sencha, xui and zepto i'm not the font of wisdom, so i'll wait for other's input.

Ideally somthing lightweight is best, full jquery is a nono, it's soooooo big it's rediculous, i'm even veering away from it on regular desktop targeted site design. one awsome project I've looked into is the Microjs project, the maintainer of which I got the chance to chat with to at a talk/pub meetup, really interesting stuff. Any other opinion or rebuttal on jqm/jqtouch I'd be interested to read.

[archblob]

As i have seen it , the layout interaction in PhoneGap is nonexistent because that's not it's purpose. All the PhoneGap projects that i've taken a look use some sort of framework that gets them around more easily on the UI and event side. As you pointed out, i think constraining ourselves to a framework will be for the best, but what i don't get is the point you have made about the size of the library?

[lukeab]

While it's not so much about the size of the library, although keeping the size down is also good, I'm more focused on the weighty nature of their pressence.

Frameworks like jqm provide a ubiquitous layout idiom that suits some apps, but ultimately is very over bearing and "samey". Often they will inject transitions and slide effects implicitly rather than us dev's explicitly setting them up in a given case. it should be down to us not to be led by the nose and have the framework railroad us into following its predetermined way of doing things.

This is where some people might disagree with me, but I think we can develop a better app if we avoid stepping into their mould. (hehe, i was gonna change that spelling, but i'm not gonna!)

[dominickm]

@lukeab / @archblob Morning guys. Just wanted to chime in on the framework front. I tend to use JQuery Mobile over Sencha with PhoneGap. However, I'd be happy to look into micro.js, however, how big is the project; meaning how widely used is it? Are there a lot of good resources that we can turn to for it.

@odysseystudio Happy to have the help!

[ghost]

I apologise for being late to comment here. How important is the file size? I have testing phonegap using plain old jQuery not the ui for the mobile. It seems to work pretty well on my phone(Android 2.3.7). 32KB (jquery-1.7.2.min.js) such a big deal? According to the storage information on my phone the application is 540KB + the data(which varies).

I am working on a interesting way to display the shows on the app. I would prefer to use jQuery. Will be posting more on it soon.

[dominickm]

@Techfix I am not sure I understand you question. Are you referring to the media's file size? Or to JQuery's?

[ghost]

Well you guys have been talking about small and light libraries. So I don't really see the point since the app logic isn't located over the internet. Plus jQuery is a good standard, however I am not keen on the UI stuff they do. I don't understand the point about ui libraries. It would be better if the UI was made from scratch. It would look better and it would work better too.

[dominickm]

@Techfix So the reason that a lot of mobile web developers turn to JQuery Mobile or Sencha Touch is that using them reduces development time. There is nothing stopping us from rolling our own, but it could be a bit more time consuming...

[ghost]

I see. In my experience with any library, I tend to spend quite an extensive amount of time learning the library inside out. Since I spent my adolescence building website templates and playing in bands. I don't really have a problem with building a custom UI. I am not disagreeing with anyone. I was just not sure about what exactly you guys were trying to decide upon.

I just create a color scheme for the app which I off the JB logo. it uses the blue in it as the main color..

[ShaneQful]

I think we should go with jquery mobile not only are more developers familiar with it but if we roll our own it will take longer and there is a higher likelihood that people will make mistakes.

[dominickm]

@Techfix Well, it is always good to learn a lib before using it ;)

@ShaneQful I have to agree with you. I think for a project like this that is catering to a community that has a lot of more junior developers would benefit from using an established lib that has plenty of documentation / support.

[ghost]

Is everyone settled on jquery mobile? After having a look at it, I quite like it. However, I don't like the normal UI stuff from jQuery but the mobile stuff is really good.

[ograycode]

My personal preference is Sencha Touch because it will adjust itself for tablets and phones, but I have not ever really used it... I do like that jquery mobile has a WYSIWYG editor though.

[lukeab]

One thing i was going to say on UI stuff and certainly for animations and transitions, we can turn to mobile supported css based transitions where supported and fall back to js based where not. But by using css, it hooks in most browsers at a lower level than js, so 3d support is there or it is just more effiecient as css rendering is tighter to the rendering engine of the browser than js.

Now how this all sits on top of the native app methods that Phonegap uses to render our work I'm not sure, but i presume some kind of native browser "panel" is used for most of the app's views, so the same css/js rules would still hold.

JQm actually has some good support for trying css animation first then falling back to js, so client performance is usually optimal, i'm not familiar with sencha touch so i don't know yet, but i imagine they do.

@ShaneQful You are responsible for the existing android JB app i see. Nice to have you on board with this too. Do you use Phonegap or just the native code ADT SDK?

[ShaneQful]

@lukeab No I do both. I'm actually currently developing a phonegap app for work but I generally try to not touch the phone gap api as much as possible and stick to what's possible inside of html. ie don't use phone gap's file api use html local storage and use the tel: protocol rather than the phone gap call api.

[ghost]

@lukeab That is a very good point; and is kind of what I was saying about a DIY UX - not quite but almost. After much thought I think jQuery mobile is the best way to go. @hothead2 I had a look a Sencha Touch, to me it looks unfinished. Some of the icon buttons and other widgets do not look as good as (mobile) jQuery's.

@ShaneQful Do you think it would be possible to use a straight HTML5 player instead of the phone gap media API? After testing my test app, It seems that phone gap is a little slow - which is not to say we couldn't use it. Is there a better alternative? I think we should still use phone gap since it handles the cross platform stuff.

[ShaneQful]

@Techfix For the audio stream its quite possible. Same with the video over rtsp. Unfortunately I don't have a device that supports HLS streaming so I couldn't tell you one way or the other for that but my view is always to use as little phone gap as always that way the app is super portable and will make a great mobile website as well. However we may have more control over the ui and the look and feel of the app if we utilize the phone gap api.

[dominickm]

Hey guys, sorry for late reply been under the gun. It sounds like we are all pretty settled on JQM, then.

The video is going to be an issue, particularity on older devices, not sure how to best handle this.

@ShaneQful I definitely, agree with you that we should use as little PhoneGap ass possible for the streaming; I'm not sure that it is very reliable for that. Has that been your experience as well.

[ghost]

I was looking into the m3u format. It looks quite easy to implement. With m3u you make requests to the server, and the server sends you the URL for the short mp3 or mp4 clips. You simply need to download the file and play it and then make a request to the server again.

This could be a way to stream efficiently what we need. All HTTP type requests though. I don't know much about rstp. apple developer has the rfc for m3u. Does m3u support video?

[lukeab]

m3u can have video references absolutely, and we can actually read the m3u into javascript and play with the meta data for display, however m3u is very simple and supports only limited data encapsulation, for compatability it works with video streaming players like vlc, but there's not alot of meta tagging we can do, it would be nicer to have the freedom to include cover art for videos, playlengths, titles and summaries in a meta data file.

So is there a format that's compatable with video players, that can encapsulate more interesting meta data so we can use it in another way also?

EDIT:Spelling

[ghost]

It was my understanding that all the other data would be request first via the XML source. That would contain the information needed for the descriptions etc... the steaming stuff would be seperate...and would be requested later. Keeping an offline copy of images ect...would save on bandwidth make frequently accessed items appear more quick.

[lukeab]

ah Yeh that's perfect, that's fine, I was just wondering why we werwe talking about or would need an m3u separate to any other metadata file, like the xml?

[ghost]

We really should be discussing the UI here. The requirements section should cover the processes and functions more. I just took the opportunity to to speak @ShaneQful. So sorry for the side track.

If we are looking at the UX from a designer or artist point of view. Artists - and myself - like to use art forums like deviant art. Which is often what artists use to advertise themselves. Although I am more than keen to get stuck into the UI stuff. I was wondering what happened to the guy on coder radio who wanted to get involved in the designer stuff? I would like to encourage the more artistic people to start designing the UX. While the developers focus on sorting the backend problems out aka the player, the libraries. I would prefer to work on the more development side as that is why I am here.

I have some icons and artwork made, but I feel that we should be calling out to the other creative people.

[ShaneQful]

@dominickm I haven't used the Phone Gap Media Api but just from reading the docs, It only supports audio and we can just as easily open a audio stream without it, using html5.

[dominickm]

Hey guys. Sorry for not being active on this thread for a few days. I've been busy with work. I agree with @Techfix Let's reign in conversation to be UX focussed and we'll deal with dependencies on another issue / thread.

[monstercameron]

An idea for the IRC stream could be that a layered approach, where the IRC is alpha'd out a little.

1. user starts live stream.
2. user want to see live chat
3. user touches display to reveal stream overlay or a button/control to reveal stream overlay
4. user can scroll through and submit text on overlay
5. to close overlay, there could be a timer or an exit control

[dominickm]

@monstercameron That's an interesting my concern is more around the UX. IE I haven't seen what I would consider a really good mobile IRC client.... and am not sure it can be done well

[therobut]

Since this is a JB specific app there is quite a bit of functionality that can be left out of the IRC feature, should we choose to include it. For instance joining and leaving channels is probably outside the scope of this project. Most of the IRC stuff can be done behind the scenes. Point being that there is less work for the IRC part than I was personally thinking at first.

That being said I don't have a good answer for how to implement IRC. Outside of texting phones don't lend themselves to text chatting very well IMO.

[ghost]

In terms of the UX, we could have a header/footer bar in the now playing page that updates the last sent message from the chat room (About 2-3 lines in length. The user could then select the header/footer which would bring up a text message like window/page. That is the previous chat entries at the top with an text area with a send button at bottom.

I think that we will need the chat to inside a page of its own since this would allow the user to press the hardware back button, to return to the page they were on before. The IRC page would need to have its heading with a back button for iPhone users.

Alternatively we could use a collapsible element with the chat page inside it.

[therobut]

Good suggestions.

If we are eager to get an initial release out it seems like IRC could be something to think about for a later release. I know personally if I'm listening on my phone I'm not usually able to chat so it seems to me like a secondary priority. I could be wrong though what do you guys think?