Responsive Skin

Last modified by Vincent Massol on 2024/02/26 17:52




The goal of this project is to create a fluid and responsive skin for XWIKI in order to accommodate the wide range of web capable device.


Though the end result will be entirely fluid-changing as a web browser is resized-it will have semantic breakpoints (currently phone, tablet, desktop) in order to create a true tailored experience in common devices. As per UXBooth and StatCounter, these breakpoints will at the moment be (width in px): 320, 480(mobile), 640, 768(tablet), 1024,1366(desktop)). 480, 768. 1366 will be the focus of the first iteration. 

After the general layout is completed, typography will be checked. Especially with the advent of super-phones with high-density px screen, this will be necessary. (Support from devs with phones to test real world scenarios would be appreciated (I have access to bb, (wvga) android, wp). 

Images are removed except for a 2x2px  block for the dotted background (that itself could be removed) to speed up loading time and remove any additional server polling. 

Design will be bottom up, as a result of the limitation of mobile devices. 

Tentative Timeline

Holistic = overall layout of the skin.

Week 1 [21 May - 25 May]. Design explorations: holistic view (UI wireframe) [90%]
Week 2 [28 May - 1 June]. Design explorations: common widgets/features(UI wireframe) [100%] MILESTONE 1: Clear concept of what is to be coded/written|t=extensions&p=1&l=30&s=doc.creationDate&d=desc&name=app
Week 3 [4 June - 8 June]. Raw Semantics that work cross platform [100%]
Week 4 [11 June - 15 June]. Desktop implementation (holistic) (css & js) [opera, chrome, safari, ie] [100%]
Week 5 [18 June - 22 June]. Desktop implementation (holistic) (css & js) [opera, chrome, safari, ie] (this weeks specifically watered down browser (eg. ie7, ie6?). begin perfecting fluidity of the responsive design (holistic) until tablet size/mobile size/device specific changes (eg. dropdown for mobile) [100%]
Week 6 [25 June - 29 June]. perfecting fluidity of the responsive design (holistic) until tablet size/mobile size/device specific changes (eg. dropdown for mobile) [90%]  MILESTONE 2: Codes are written and ready to be implemented into XWiki.
Week 7-9 [2 July - 13 July]. implementing into xwiki [40%] [midterm] MILESTONE 3: Codes are implemented, and usable
Week 9-10 [16 July - 27 July]. Choose priority of features to be worked on to be made responsive. Begin working on features that should be made responsive [100%] [search suggest, livetables, blog, color themes]
Week 11 [30 July - 3 Aug]. Continue working on features   MILESTONE 4: Chosen features are working and responsive [100%]
Week 12 [6 Aug - 10 Aug].  Clean up code/optimize/bug fixes etc. [100%]
Week 13 [13 Aug]. MILESTONE 5: Create distributable version

See how everything is actually developing (demo):
Download src for implementation on XWiki:


  • Utilizing true drop down in order to take advantage of a mobile OS' dropdown system (eg. iPhone, further reference at New York Times from their tablet app. a la this)
  • Should there be an attempt to support 100% non-javascript capable browser? esp. since some core functions of xwiki requires javascript (such as live tables) if I remember correctly.
    *how far back do we specifically support? ie6?

Mock up

Columns are removed, and everything is vertically stacked. The light grayish background will help to separate these widgets, since it will become unclear with everything stacked (new section or another widget?). Quicklinks font is bigger to facilitate small screens. Alternatively, like in "spaces" links, the links are given a gray background with a block display in order to help finger pressing while still keeping typography flow.

Mock up 2

With the advice of the community, here is another version of the skinthis time more unique and less colibri:

Mock up 3

This design divides navigation into 3, corresponding with borders. As the user hovers nears the edge, it would reveal the whole link/more info. The overflowed text serves to give them the idea there is more. By putting the navigation in the borders, it becomes more static in a waythat is on each new page, the "navigation links" placement will always be the same area. Also, by detaching the links from the content, its size has more flexibility allowing it to be bigger without interrupting the flow of text allowing for bigger size clickable area. 

In the mobile version, instead of hovering, the user would click. So it's a bit similar to the Mobile Patterns[1] link Caty sent a while back since it is like a sidebar to be revealed kind of thing.

Furthermore, this skin will really put the content front and center. And again, this mockup is incomplete, i just wanted to give you a heads up on this current exploration and was wondering your thoughts. 

Mock up 4

The idea is that the sidebar would be replicated,
but hidden in the mobile (except for the hint that it's there.)

Everything non-content is combined. I think that if you are looking at the
comments/attachment/other sections, you are not thinking about navigating
away from the page so the nav section is not that needed. So this
consolidates/saves space. Let me know if this is the wrong mentality. 

Mock up 5

Mock up 5B

The goal is to consolidate everything to a section. (breadcrumbs/where you
are & navigation/supplementary info & content)
eg. the page breadcrumb has been added into the global bread crumb (is this
possible?); all page navigation/meta are in the sidebar (such that, again,
the main area is just content, and the sidebar are all additional infos) 

The way i'm envisioning the responsive design for the content is like this:
When the screen is big enough, it will become 2 column. as we hit smaller
screen (eg. tablet) it will become one column. Then finally, the page would
collapse such that only the header is visible for mobile (thus also
becoming a table of contents) until being tapped, which will open the div. 

As mentioned before, the same "sidebar" will appear when you click the
navigation hint on mobile (so it will be in a way consistent). Though with
this development i should probably add more than navigation (eg. NAVIGATION
/ INFO / ETC. or something). 

Approach to color themes

In order to have the most diverse amount of color themes, the skin will have 2 options. One in which it uses xwiki's built in color themes (allowing the use of already sundry color themes available), and a second one which allows the user to choose a custom color theme made specifically for the skin (more unique and specific looking). 


Get Connected