[FM Discuss] UI Challenge

Tue Aug 31 08:57:11 PDT 2010

Collaborative workflows should make people more important at every stage 
- it should just take a lot of the unpleasant grunt work out of the task 
of creating ...

Technology will never replace designers, artists ... or writers!  :-)
> ------------------------------
>
> Message: 5
> Date: Tue, 31 Aug 2010 17:00:54 +0200
> From: adam <adam at xs4all.nl>
> To: discuss at lists.flossmanuals.net
> Subject: Re: [FM Discuss] UI Challenge
> Message-ID: <1283266854.1692.54.camel at esetera>
> Content-Type: text/plain; charset="UTF-8"
>
> hello,
>
> On Tue, 2010-08-31 at 08:22 -0500, James Simmons wrote:
>   
>> Adam,
>>
>> Rather than make the interface more elaborate I'd like to have some
>> simple (I hope) things:
>>
>>     
>
> okedoke...
>
>   
>> 1).  A more reasonable default style sheet.  The one we have uses
>> really big fonts for titles, sections, TOC, and really small ones for
>> content.  It also makes a lot of stuff ALL CAPS  when it really should
>> not.  The style sheet I'm putting together for MYOSA might be the
>> basis for a reasonable default, and it uses the same fonts that
>> Collaborative Futures uses.
>>
>>     
>
> yes, i think we need to tweak the default but it will never please
> everyone, aesthetics being what they are :) I have a book designer on
> the job this week as it happens...
>
>   
>> 2).  More reasonable default behavior for page breaks.  A heading (h2,
>> h3) should never be left at the bottom of a page with the section
>> following it on the next page.  A table should not be split across
>> pages if it can be avoided.  On the other hand a list of bullets CAN
>> be split across pages.
>>     
>
> this is quite an issue. its such an issue that neither google, apple, or
> mozilla have solved this ie. good css control of page based media.
> believe it or not we are actually pitching to mozilla to solve this
> problem for them and they are taking us pretty seriously although no
> word yet. so, its got to be a pretty huge issue if they come to us to
> solve it right ;)
>
> so...at the moment you need to manage it a little manually mostly
> because we do not have page-break-after:avoid control as it is not
> supported by webkit or gecko...we are doing what we can to fix it (as
> per above) and additionally doug had an idea to hack divs around
> specific elements to help them stick together.... neither of us liked
> that since it is a hack and not the right way to do it at all. however,
> perhaps we can add it as a hacky option - something like a opt-in for
> "add divs around h2 and h3"...then they would stick together 
>
>
> however, i do not think it will be soon when page breaks form nicely
> around paragraphs automagically. default behaviours do as good as they
> can but are never as good as manually tweaking. thats why people are
> designers and machines arent. so you will have to manually juggle
> paragraph breaks to make them break nicely. remember, this is also what
> Desktop Publishing entails..all this manual control. we dont want this
> paradigm...we want to be fast and nimble and at the same time we want to
> get a reasonable default - but I am not sure we can, nor do i think its
> necessarily the right approach, to consider that this method will 'make
> everything perfect'...its a different process, and there might just be a
> line where you either accept some nuances but saviour the fact you get
> all the other advantages of an amazing online collaborative tool set, or
> choose to :
> 1. do some manual tweaks or
> 2. quit and do it in DTP.
>
>   
>> 3).  The style sheet for the web version of an FM should treat
>> preformatted text like the PDF does.  Right now if a line is too long
>> on the web it wraps to the next line, but in the PDF it gets
>> truncated.  If the text was truncated in pretty much the same place on
>> the web as it would be in the PDF with the default PRE font (Courier
>> 12 pts please) then code examples could be formatted on the web and it
>> would be reasonably likely that they would be good in the PDF
>> generated with the default styles.
>>     
>
> we can get things close but i dont think we will get everything 100% the
> same (see acos notes from earlier today) ... but i take your point that
> it would be nice to get more clarity via the web interface on how
> elements will work in pdf
>
>
>   
>> On my second book I have the services of a talented artist and people
>> who are really interested in book design.  On MYOSA I didn't have that
>> and didn't think I would need it.  I was hoping that OBJAVI would be
>> like LyX, where you don't really get to design how your pages will
>> look but they come out looking great anyway.
>>     
>
> well, LyX is latex and thats a whole other ball game. I think James you
> need to let go of that paradigm a little. We are not Latex, we are a
> collaborative fast moving online environment focusing on simple easy to
> use tools, sociability, collaboration and output of good looking books
> in multiple formats _quickly_. write, publish, write, publish...some FM
> books I have 're-published' 10-15 times in one day as updates came to
> hand. re-published after updates came in from all around the world and
> re-published in _both_ html form and book form...that is not Latex, that
> is something else all together...(in my opinion the books also looked
> pretty good)
>
> but i take your points, mainly i think we can improve the defaults, but
> also as i mentioned before, we need a better interface for determining
> css options for publishing...
>
> so...thanks thanks thanks for all the points. we will get there and make
> you happier ;) and i hope with your feedback and keeping people like you
> onboard we can get there quicker :)
>
> adam
>
>
>
>   
>> James Simmons
>>
>>
>>
>> On Mon, Aug 30, 2010 at 11:42 AM, adam hyde <adam at flossmanuals.net> wrote:
>>     
>>> okedoke....
>>>
>>>
>>> so, the series of challenge posts asking for help with css, python, js
>>> etc has been really super. we have solved a lot of things this way with
>>> advice and help from the community (thats you :)
>>>
>>> so...big big thanks to everyone that has come to the assistance of booki
>>> through these mails :)
>>>
>>> so...i thought i would take this a step further and put rather a bigger
>>> challenge on the table. I have stepped back and observed how Booki has
>>> been used for pdf design - seeing how people (ie. Mushon and the RDC)
>>> are solving these issues. There has been some pretty cool things come
>>> out of this. Mushon in particular has been very active on the dev list
>>> (http://lists.flossmanuals.net/listinfo.cgi/booki-dev-flossmanuals.net)
>>> and helped us work out a lot of issues AND he has made some big strides
>>> forward with experimenting with CSS and book design using Booki/Objavi
>>>
>>> RDC and James are also doing great exploratory work in this area as you
>>> have seen through the posts to the list.
>>>
>>> One thing that strikes me, is that I think we need to consider providing
>>> an interface to assist people design pdf using the booki export tab...
>>>       
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.flossmanuals.net
>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net
>>     
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.flossmanuals.net
> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net
>
>
> End of Discuss Digest, Vol 39, Issue 48
> ***************************************
>
>
>