On 8 Mar 2015, at 8:07 pm, jan i <[email protected]> wrote: > > On Sunday, March 8, 2015, Peter Kelly <[email protected]> wrote: > >>> On 8 Mar 2015, at 3:10 pm, jan i <[email protected] <javascript:;>> wrote: >>> >>> Important is that the client is based on responsive design, using e.g. >>> foundation. >> >> Note that “responsive design” in the context of the editor (or at least >> how I’ve always used the term) simply refers to the fact that you can >> resize your browser window, or view a document on a tablet/phone which you >> can rotate, and the text will automatically be reflowed. This has always >> been part of web browsers since the beginning (despite a huge army of >> print-oriented design people trying to fight it) - it does not require any >> special frameworks or libraries, as it’s inherent to the way that HTML >> layout works by default. >> >> Ups I actually meant more...,.on a big screen you can have more gadgets > visible in form of e.g. icons. You can have a topmrnu with sub menues > etc...,..on a small screen som of this would be present and e.g, menus > would typically fold differently. > > Our Homepage is an example of something that is more than changing the text > fliw.
Are you referring to the need for responsiveness in the editing UI, or in the documents themselves? I would argue that responsiveness in the documents themselves is not realistically achievable, because although we could certainly achieve it in HTML, formats like docx and odf do not cater for this at all, and since that’s what a large proportion of users are going to be saving their documents in, there’s little point in supporting it in the editor. I agree however that a responsive design approach for the UI itself is both desirable and achievable. — Dr Peter M. Kelly [email protected] PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
