5 Dec
2011
5 Dec
'11
1:21 a.m.
Hi Ludovic,
Thanks a lot for your input. Please see my comment below.
On Nov 29, 2011, at 11:09 PM, Ludovic Dubost wrote:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2011/11/29 Mihai Paun <mpaun(a)xwiki.com>
In terms of adapting wiki content of pages to mobile, all I can do is treat the output of
wiki syntax and make it mobile-friendly. A trivial example would be reducing the size of
the headings according to the device size. Adapting other content for mobile is up to the
developer who writes code inside a page.
About the livetable, after giving it more thought I believe the optimal way to handle
this is to add some mobile specific code and handle the output of the livetable
differently. For instance, when the page is loaded on a mobile device, we only display
just the first column, which is usually the one with the title of the document, and we
also keep the sorting, filtering and pagination behaviour.
Hello Guillaume,
First of all, thank you for your feedback.
On Nov 28, 2011, at 1:31 PM, Guillaume Lerouge wrote:
want
with a
quality.
Hi,
I believe it is very important to go further just wiki content of pages. We
need to support what actually is in the content of pages (sheets, livetable
and so).
Otherwise I believe you will have most of your content not available in a
good maner. Hi Mihai,
I'm glad to see some work being done in this direction :-)
Please see my comments below.
On Mon, Nov 28, 2011 at 11:45 AM, Mihai Paun <mpaun(a)xwiki.com> wrote:
> Hello devs,
>
> As some of you may know, I recently took on the challenge of developing
a
> mobile compatible version of XWiki
Enterprise. The objective of this
> development is to come up with an optimized solution for smartphone and
> tablet users, both from a technological point of view (using HTML5, CSS3
> and perhaps mobile oriented JS libraries) and from a contextual
perspective
> (when do mobile users use a wiki and most
especially how they interact
with
it).
Regarding this, do you have a list of the main actions you expect mobile
users to perform? For instance I'm not sure that many users will even to edit wiki pages (it's going to be really
complex on a small screen and
the WYSIWYG editor will not work). Adding a comment might be a more
frequent use case for instance.
Yes, we've created the mockups based on the assumption that the main
functionality will be reading content. Therefore, we have:
- Search button on the top right corner, position fixed, that will either
trigger a search form to show up or it will link to the search page
- Breadcrumbs, so that the user can navigate back through the wiki
- Icons of the most accessed spaces on the dashboard (first page that the
user will see after opening the wiki or after clicking on the home icon)
- Search form on the dashboard (as you see we rely heavily on search)
Besides browsing for content, other actions will be:
- Creating documents, spaces
- Browsing/Adding comments
- Editing content: as I said in one of the notes from the mockups, the
performance of the WYSIWYG editor on mobile remains to be assessed and I'm
in favor of using only the text editor. Nevertheless, I'll have a
discussion with Marius and see how we can measure the performance. In any
case, it will be considered best effort within the first release timeframe.
For the record, I have yet to see a wysiwyg editor for mobile. There seems
to be one implemented in the Google Docs app for Android but couldn't find
it: http://www.quora.com/Is-there-a-WYSIWYG-editor-for-mobile-editing
- Browse attachments (Adding attachments is a bit tricky since the file
upload control is not included in the mobile web standards, but many
devices still accept it - Android from 2.2, iOS not even in 5.x)
- Login, register
- View user profile and perhaps edit it (also best effort)
- Browse a list of the other users (User Directory)
The targeted platforms that I plan to support, since I'm only one guy
with
> limited time, are post Android 2.2 and post
iOs 4.x platforms. The first
> release is planned for the end of January 2012.
>
> Because simply applying media queries to an existing desktop site won't
> completely optimize a mobile experience, I thought of building one from
the
> ground up - this would imply a complete
overhaul coupled with
> server/front-side adaptation (what Facebook, Google and most top
internet
> brands are doing)
>
> Some of the key aspects that I plan to focus on are: functionality and
user
> experience (establish what needs mobile users
have in a wiki context),
> performance, future-proofness (easily adaptable for the ever-changing
> market of mobile devices, particularly in terms of screen size,
resolution
> and browser changes), flexibility (easiness
of adapting the skin to a
> clients' needs)
>
> I am considering using an adapted version of mobile boilerplate, which
is a
> very popular baseline template being used by
a lot of individuals who
are
> developing a mobile web app
(http://html5boilerplate.com/mobile), and
> build
> on top of it a new yet familiar user-experience, adapted to mobile
context.
>
> In terms of functionality, my take is that the primary function of a
user
who is
navigating a wiki is either looking for information (content) or
trying to edit information. Administration or using the wiki to build
structured applications falls under the use cases that the user won't be
interested in doing. Thus, in the proposed attached mockups there's no
schema for an Administration area or editing a document in object/class
mode.
+1
The advantage of starting from scratch will allow me to strip everything
> that's unnecessary from the .vm files thus increasing performance; one
> example would be reducing requests => saving bandwidth.
>
> Following a discussion with our designers, Caty and Max, we came up > couple of mockups that I believe can stand as
the foundation for this
> mobile experience. Please find them here:
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileSkinv3or
> here in a higher quality: http://db.tt/8vX9OcBZ
>
> Another approach, for which I also gave a lot of thought, is to make an
> existing skin work passably well on a range of mobile devices by using
> media-queries and adjusting a great deal of .vm's. This will offer an
> "responsive design" experience, similar to the examples that can be
found
> here: http://mediaqueri.es/
>
> This approach has a lot of advocates and has gained quite an enthusiasm
> lately (there's even a book written on the topic:
> http://www.abookapart.com/products/responsive-web-design). Note that
one
> particularity of the websites is that most of
them have been built with
a
> "mobile first"
(http://www.lukew.com/ff/entry.asp?933) approach in
mind,
> not having to adapt an existing desktop
website. Secondly, these are
mainly
> presentation websites, far from the scope of
our product.
>
> However, I've been pondering about this alternative a lot recently, and
I
> am thinking about going back to the drawing
board and make an analysis
of
> what exactly would take to develop the mobile
skin this way and also
have a
> thorough look at the code to see if the
current markup can be easily
> adjusted to offer a responsive experience. My mainly concern is that
> instead of coming up with something clean, things will become instead
> messier, probably having to be forced to adopt varios unorthodox
techniques
or bad
practices in the mobile web, such as using extra JS code to move
markup around.
Both approaches are interesting. I've seen several examples of responsive
layouts lately and I must say that I was quite impressed by their One such example is the new version of the Boston
Globe website:
http://bostonglobe.com/ which adapts from large screens to phone
screens.
Yes, I am also a big fan of this technique but unfortunately I don't find
it entirely suitable in our case. I highly recommend this short read on the
topic of how these "responsive" websites are created:
http://yiibu.com/about/site/
The other advantage of this is that there is only 1 skin to maintain
instead of several different ones, and new applications automatically
benefit from the fluid design. A big question would be, what to do with
livetables in that context?
That's true. This is as much of an advantage as it is a disadvantage with
my first approach. The costs of maintaining another codebase is strictly
related to what we plan to do with the mobile skin when it will be ready.
Include it in the platform, use it as a selling point?
About the livetable, I consider it very valuable for filtering and sorting
documents, thus for searching and reading content. From the tests I've made
on my devices, on iOs 5 and Android 2.3.3, it behaves well but I cannot
find a way of introducing it in my mockups.
The problem with the livetable is that it's only suitable for screen sizes
larger than the one of an iPad.
However, this does not mean that the entry point of the mobile skin cannot
be something specific to mobile (a dashboard and activity stream
specifically made for mobile).
But if you get to a page which has scripting or javascript in it , we need
to find a way to make it work natively.
Concerning the iPad mode, I think it would be worth it to really discuss if
a specific mobile interface is needed. The screen real estate of an iPad is
already quite good and we could imagine that a slightly modified skin could
be enough (with panels hided by default for instance).
It's true that the screen size of an iPad or any other tablet allows us to display
most of the content in a clear and concise way as on desktop. But, we're still not
getting away from the fundamentally different way of using the two devices (desktop vs
tablet). Hovering, for instance, is ruled out in a mobile context, thus the annotations
feature and submenus. So, my target still remains to make a skin that is consistent both
for tablets and smartphones. At least that's how I envision it unless we collectively
decide otherwise.
Mihai
Ludovic
I would definitely be interested in an exploration of this option
(complexity, advantages, features to expose...) before we engage in a
redesign using an external, mobile-only framework.
To sum it up:
- It's very hard, if not impossible to adapt an existing website and make
it "responsive" (particularly in terms of modifying mark-up order)
- One codebase to maintain
- Less complex to develop since we're talking only about removing stuff
that is not suitable for mobile devices (e.g. Panels)
- We're not improving anything in terms of performance since we're
displaying:none a bunch of html elements which are loaded anyway;
performance is a crucial aspect for mobile devices.
Looking forward to the final product,
I would like to get more feedback from the other devs.
Thank you,
Mihai
Guillaume
I am gladly accepting any kind of input on this.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thank you,
Mihai
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs