29 Nov
2011
29 Nov
'11
7:06 p.m.
Hello Guillaume,
First of all, thank you for your feedback.
On Nov 28, 2011, at 1:31 PM, Guillaume Lerouge wrote:
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:
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)
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 want
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.
The targeted platforms that I plan to support, since I'm only one guy with
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/
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 with a
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/MobileSkinv3 or
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 quality.
One such example is the new version of the Boston Globe website:
http://bostonglobe.com/ which adapts from large screens to phone screens.
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.
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.
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