[Freedombox-discuss] [FBox-Visual] New FBx Foundation Website Theme

Wed Apr 4 21:59:51 UTC 2012

Sean,

I'm glad to hear I didn't hurt your feelings :P

I only used git once and need to dig my way into this again.
If you think it is worth it let's go for that. Learning a bit more git 
won't hurt (in the long run).
I read on the ikiwikipage that every wiki has a sandbox built into it - 
does that include the theming part of the system? (maybe that way we can 
use the current live version?)

Anyway, just let me know what you need me to do!

@flag like on foojbook.com: I think it is way too subtle:
transparent, just icon without text and then way up in the edge with no 
padding?
You'd have to be sherlock holmes to find that :D

Looking forward to the testing environment!

Robert

On 04/04/12 17:14, Sean O'Brien wrote:
> Robert -
>
> No more need to go back and forth on this, the current design looks nice
> and clean, and I'm not married to the footer I came up with :P
>
> We're still going to need a testing environment for this.  I think the
> best way to do it may be setting up a separate ikiwiki install.  If you
> don't use git, I will also put together a tarball to download.  The
> templating system takes a completely different approach than ours with
> HTML5 (parsing different markup before pageload based upon user-agent
> string).  Besides that, it's just smart copy/paste from what we have
> now, plus these dynamic elements:
>
> * only loading the intro quote/video div for the home/news page
> * truncating the latest news item for the home/news page
> * generating those news archive links with dates
> * translation dropdown at top.  I like the little flag that comes on the
> default friendica template (e.g. https://foojbook.net) so I'll try
> something like that that floats right in the header
>
> So, I'll create a testing environment and we can go from there.
>
> ~ Sean
>
>
> On 04/04/2012 07:59 AM, Robert Martinez wrote:
>>
>> On 02/04/12 18:03, Sean O'Brien wrote:
>>> Let's see if we can get this rolling within a week; if there are only
>>> minor criticisms at this point I think that's reasonable.
>>>
>>> Links to the two (slightly different) themes so far:
>>> http://mray.de/fbxfoundation_robert/theme.html
>>> http://seandiggity.com/fbxfoundation/theme.html
>>>
>>>
>>> Robert -
>>>
>>> Here's a list of the current issues, and my thoughts on them:
>>>
>>> * Change in background tile: I like the grittier "concrete" one better,
>>> just didn't have the pattern to work with, so I went with the diagonal
>>> tiles.
>> Ok great.
>>
>>> * Width of the main content: Is there a reason to shrink the design?
>>> This is a very wordy website, likely to fill in with even more text.
>>> We're already using a big font size and a lot of padding around the
>>> content, so I think it's a bad idea.  For mobile views, we can start the
>>> zoom at 100% and let users zoom in/out as desired.  Or we take a look at
>>> the Bootstrap javascript/css and try to better integrate the
>>> "responsive" stuff they've done so that the mobile view is different and
>>> more compact horizontally, without having two separate themes (the view
>>> wouldn't change based upon user-agent string, but the pixel size of the
>>> viewport).
>> My reason is exactly the one that this will be a wordy website.
>> The current character count per line in my current version of the theme
>> is 100 over the full length. The front page is an exception here.
>> This is also why my initial mockup was even smaller. I think going
>> beyond 100 characters per line won't be appreciated by the readers. The
>> goal isn't to fit in as much content as possible, but to make it easy to
>> read.
>> Optimizing for mobile viewing is always a good idea, but i would do that
>> in a second iteration.
>> I don't care if the look gets changed completely, responsive web design
>> rocks.
>>
>>
>>> * Footer: Maybe I'm just partial but I think the one I came up with
>>> looks nice, separates the footer from the main content well, and isn't
>>> distracting.  The gray tones should go well with the "concrete"
>>> background pattern too.
>> In the end this is probably more about personal preference.
>> my decision not to mirror the top bar was based on the strong emphasis.
>> The design does not rely on having a "basement" nor was there a need to
>> emphasize anything. all it needs in my eyes is a clearly visible end.
>> Also i like the openness towards the bottom a lot.
>> I just finished the work on the footer - so maybe that changes a bit.
>>
>>> * favicon: Thanks for changing this; do you have a larger version so
>>> that I can also change the "web clip" icons for iOS?
>> yes i can create a svg version of it so you can extract any size you need.
>> i just created a 3-pronged version for very small sizes, too. both
>> attached.
>>
>>> * Top navigation: Left-aligning this is fine.  Still not crazy about the
>>> "sea green", but I don't have another color that doesn't make us look
>>> like Twitter or Drupal.
>> i admit the green is something special. maybe too special?
>> For me it works for those reasons: it nicely catches the color of the
>> green triangle underneath and integrates it on the blue. it very clearly
>> keeps its distance to the logotype AND the content, and finally the
>> white active/hover state works awesome to highlight the active menu points.
>> going for a completely new color is out of the question for me, the
>> solution would be to just invert normal<->  active.
>>
>>> * Bottom nav links: If we're going to be doing a left-aligned grid for
>>> most content, these should be left-aligned too, and probably moved
>>> closer to the footer than the main content.  Using the green here is
>>> better than the blue in my design, but I'm not sold on the green
>>> diagonal line.  Maybe just use the gray line.png from above?
>> I have no hard feelings for the line since i just introduced t to make a
>> clear statement that this is the end of the normal content. we can
>> remove it.
>> the center alignment is another tool that i wouldn't discard - a sudden
>> switch of alignment, font size and color are great subtle hints that
>> there is something ending/beginning. therefore i would also keep enough
>> space between content and footer to underline the efforts to separate them.
>>
>>> * News links: We should be able to pull the date from ikiwiki and print
>>> that out without any trouble.  We'd have to make sure the links were
>>> sorted by date anyway.
>> ok great, but that sounds like something we can address in the next
>> iteration.
>> i have some small faint green typo in mind, left aligned under the
>> title. but we can care about that later.
>>
>>> * RSS and Atom links: Why not have them floating on the right of the
>>> news links?  Makes that area of the screen look very busy if they're
>>> floating left (i.e. in the center of the design).
>> I regard those links as content of the Archive box, which is completely
>> left aligned. So steping out of this alignment seems to bring more
>> disturbance in the design.
>> Apart from that I'm still not sure if the Archive box is really the
>> right place - i just arranged them there to fit your markup :P
>> what do you think about putting them over the first news entry along
>> with the text "NEWS" just like in my mockup (instead of the gray line)?
>>
>>> * Language menu: Making a dropdown menu in the top-right isn't a big
>>> deal, but I'd also say it's wise to keep the footer how it is
>>> (especially because it shows the current state of the translations).
>> if the drop-down could also contain this information there shouldn't be
>> a problem.
>> Putting them at the bottom is REALLY hiding the translations.
>> Every foreign reader would first have to read the whole page before
>> encountering them!
>> I doubt it is common to search for languages at the bottom of the page.
>> And hey! we have lots of space on the top right :)
>>
>>
>>> * Intro quote: Shortening it is fine, but making it too prominent on
>>> every page is a bad idea.  I've written a short script before that goes
>>> through a text file or a DB of quotes, stores them in a session array
>>> and shuffles the array, then grabs one line of the array to print until
>>> the array is empty.  If we do go with random short quotes, it's a good
>>> approach because the user doesn't see the same quote twice until she has
>>> seen them all during a browser session.
>> This is more a content than a design issue.
>> Are you talking about randomly replacing Eben Moglens quote?
>> I'm not sure even this quote works well, replacing randomly would work
>> less.
>> We should make the effort to distill a very short and easy Sentence that
>> gives a quick rough impression about what this here is all about.
>> Eben Moglen may say the right thing there, but for the front page it is
>> too long and too complicated imho.
>>
>>
>>> * Video: Clipping the video and hosting it on our site seems like the
>>> best approach.  I'd be happy to clip a video, although working from a
>>> low-quality version is probably not best.  We should also have a page
>>> linking out to youtube, vimeo, etc. for the videos there (or perhaps our
>>> own hosted versions).  If we're looking for a newer vid, can we get a
>>> video of Bdale's keynote at FOSDEM?
>>>
>>>
>>> The next step is just pasting the markup etc. into ikiwiki's templates
>>> and making sure it works.  I can test locally, but pushing to the git
>>> repo would change the actual site.  So, let's make any final changes to
>>> these demos (the commentary above is probably my last contribution to
>>> that), get it into ikiwiki, and do some testing.
>>>
>> In order to avoid confusion i would just link to the video that was
>> linked on the old theme.
>> this should be resolved separately since the whole subtitle issue isn't
>> clear.
>>
>>
>> To wrap up my updated version:
>>
>> http://mray.de/fbxfoundation_robert/robert_mockup01.jpg
>> http://mray.de/fbxfoundation_robert/theme.html
>> http://mray.de/fbxfoundation_robert.tar.bz2
>>
>>