Anonymous Login
2020-07-04 21:53 PDT
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000568Pending Requests[All Projects] Generalpublic2010-09-02 10:022014-01-21 17:54
ReporterKyle Skrinak 
Assigned Tocaseydk 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
Product Version 
Target VersionFixed in VersionAdd On Modules 
Summary0000568: Add mobile device support
DescriptionAdd the ability to "compress" or optimize a subset of views for mobile devices. I'm partial to an iphone screen dimension, but we should include blackberry and other such devices.
TagsNo tags attached.
Attached Files

-Relationships
related to 0000092closedcaseydk WAP Enabled Version 
related to 0000093closedcaseydk iPhone template 
+Relationships

-Notes

~0001852

sarexpert (reporter)

2011-04-10 10:20

 Would it be possible to do this by increments? For example when accessing each screen, expand the display for small screens. A simple place to start would be the login screen which is a chore to use on an iPhone now.
Similarly the contacts screen could be reduced to be readable.

~0001853

caseydk (administrator)

2011-04-10 11:19

 I'm +100 on doing something like this.

We can do *some* things with User Agent detection or screen size detection but I think sarexpert highlights a potentially bigger problem. We just have a lot of info on the screen.

What if we came up with better pagination when on mobile? 10 items instead of 50?
What if we had a way to filter the "most recently updated" items to the beginning of the list?
What if we had a "simple view" with a subset of fields and an "advanced" view with all the fields for things like Projects & Tasks and defaulted to "simple view" for mobile?

Would any of those solve some of the problems?
(I'm just making stuff up here, feel free to come up with better/more ideas.)

~0001854

Kyle Skrinak (reporter)

2011-04-10 11:35

 Firstly, start at the top (as saraexpert does) screen res. Excellent article here: http://sender11.typepad.com/sender11/2008/04/mobile-screen-s.html recommends targetting a 240 x 320 screen size. On the head of a pin, sure.

I'm not in favor of browser detection; rather, use a mobile link for the view, i.e., w2psite.com/mobile (or mobile.w2psite.com for the apache-comfortable)

Now I'm curious about use case, and this will vary wildly. Here's my common scenario.
Load my w2p page/tasks/todo page. WAY too much info for mobile. What do I need to know on my mobile? Past due and due-today events. I don't care what the start date, duration, and all the ways into a task; 2 columns for a simple view. Easy clutter cleanup! However, I need to know "Title" and Due Date" of all past due and due today todo/tasks. Clicking on these items would then bring us to a detail page, as is but now I'm out of a use-case.

Exciting stuff! I've just moved to Android, and it would be sweet pragmatically access my W2P from that phone

~0003157

caseydk (administrator)

2014-01-01 17:10

 This is handled via the responsive Bootstrap theme:
https://github.com/web2project/style-bootstrap
+Notes

-Issue History
Date Modified Username Field Change
2010-09-02 10:02 Kyle Skrinak New Issue
2010-12-18 19:46 caseydk Category Browser Compatibility => User Interface
2011-02-17 08:41 caseydk Relationship added related to 0000092
2011-02-17 08:41 caseydk Relationship added related to 0000093
2011-04-10 10:20 sarexpert Note Added: 0001852
2011-04-10 11:19 caseydk Note Added: 0001853
2011-04-10 11:35 Kyle Skrinak Note Added: 0001854
2014-01-01 17:10 caseydk Note Added: 0003157
2014-01-01 17:10 caseydk Status new => resolved
2014-01-01 17:10 caseydk Resolution open => fixed
2014-01-01 17:10 caseydk Assigned To => caseydk
2014-01-21 17:54 caseydk Fixed in Version => Add On Modules
2014-01-21 17:54 caseydk Status resolved => closed
+Issue History