Tags:
create new tag
, view all tags

Pattern Skin Dev Archive 1 of 2

RE: Page titles and forms

On observing the active Pattern Skin on the Diemen Repository I see an item which I think is a mistake. The title form is a good idea and I like it. However I think the only the subtitle should be open to users to modify -- the title should be the page's actual name in expanded form, e.g. "Pattern Skin Dev". The problem is that if you allow the title to be different from the page name it can get lost. If I'm editing another page and I try and create a wikiword link to PatternSkinDevelopment, because that is what the title is, it won't work because the page is actually PatternSkinDev.

There are special case topics which need to be treated differently - WebHome to be titled as 'Diemen Patterns Repository' - but I think a different mechanism needs to be used for these. Like leaving the title form fields blank and putting the title in the page as a header (or whatever).

-- MattWilkie - 13 Jun 2003

Yes, I see your point. Lately I have been cleaning up the Repository pages and I also noticed that I needed custom subtitles only, except for the homepage. I think this is a problem for more twiki sites: usually you don't call your homepage "HomePage", or "WebHome". I called it "Home_" so it is a wiki word but rendered as "Home". This is useful for parent-child navigation, like the breadcrumb - but I still wouldn't want "Home" as a title.

I am not sure what would be the best approach here. Need to rethink this.

I want to have the title automatically inserted so each page starts the same way, and writers don't need to think about inserting a

---+
tag. When you include a toc in your page you don't want to have the page title in the list, so the title should be in
H1
tags. So this really needs to be automated. Also nice to have titles in color, don't you think?

Another thing about the title form is that you cannot use another form on the edit page, or you would need to combine forms. And it is logical to put a title form at the top, and other forms at the bottom of the page. So the title form should not be a WebForm, but a custom one that belongs to the skin.

I still need to change the preview template so the title is shown there too.

-- ArthurClemens - 14 Jun 2003

You could skip using a form and use a custom page template instead. It might look like this:

<h1 id="title">%TOPIC%</h1>
_...your subtitle goes here, delete if you don't need one..._


-- %MAINWEB%.%USERNAME%

This takes care of automatically inserting the title, while giving it an attribute so CSS can colourise it. It looks a bit clunky in edit mode, but on the other hand it is just one line.

I dunno about the subtitle bit, asking people to delete stuff before they even start seems against the grain; maybe javascript could be used to highlight the phrase so that it could be deleted with a single key stroke? Nah, I don't like that either. Better to just tell people "this is how you add a subtitle".

-- MattWilkie - 17 Jun 2003

Hmm, but the users would still have to remember to use lowercase h1 and h2 tags, and not

---+
so page titles are not included in TOCs. Or they have to remember to put
---+!!
to exclude it from the TOC.

I still prefer to have the title autogenerated. Then you also have the title in topics like WebTopicList (compare: http://www.visiblearea.com/cgi-bin/twiki/view/Patterns/Alphabetical_topic_list).

The subtitle is needed really only sometimes. To put it already in to be deleted would almost tell you visually that you should type a subtitle. And I agree that it should not be presented technically for something like that trivially. I could create a pop-up link Adding a subtitle to help, and in the pop-up a Copy box to help copy-paste the h2 string. This would be in line with simplicity.

So (thinking aloud) the copy-paste string would be:

<h2 style="color:%ACCENTCOLOR%;">Subtitle</h2>

Hmm again, I am not totally convinced. I would like to investigate a simple subtitle form that writes a meta variable. Is this heresy, to put content in meta variables? But the topic name is also stored elsewhere, in the filename...

-- ArthurClemens - 17 Jun 2003

Another possible method, which would require a plugin, albeit a simple one:

subtitle: my special subtitle

blah blah I put a subtitle here because as author I wanted one. 
It was  not placed there automagically, unlike the previous 
suggestion. blah blah blabityblahh

The plugin searches for {beginning of line}subtitle:{anything}{end of line} and replaces it with h2 id="subtitle" etc. This has the advantage of being user transparent. I doubt people will have trouble remembering how to do it. Notice that title is absent, this is because title is autogenerated from the filename. There still needs to be a mechanism to deal with system pages (WebHome and fiends).

-- MattWilkie - 18 Jun 2003

This plugin sounds like a good idea. If the syntax would resemble that of TWiki variables, that would be

%SUBTITLE{"mysubtitle"}%
. It is less easy to remember, but to introduce more syntax exceptions and variations is also not desirable.

About the title: is is possible to override the page title, with something like

%TITLE{"mytitle"}%
?

Added: So default

%TITLE% = %TOPIC%
, but
%TITLE%
can be overridden on the page. When displaying the page title,
%TITLE%
is used.

-- ArthurClemens - 18 Jun 2003

I deplore the %VARIABLE{"parameter"}% syntax and advise strongly against using it anywhere in user space. In perl modules and scripts and templates it is fine, but users should not have to remember and type what is essentially a programming construct in the content area. If we use this we might as well go back to using

---++!!
for "heading two, don't display in TOC" which about as hard to remember and half as hard to type.

-- MattWilkie - 19 Jun 2003

RE: Singleword_

Arthur - regarding your use of Singleword_, can you tell me what you think of the syntax introduced by SingletonWikiWordPlugin?

-- MartinCleaver - 14 Jun 2003

Viewed in isolation, the prefix dot looks more logical than the suffix underscore. In fact, I also played at first with this dot syntax, but I got into problems on my Mac that hides all files with a dot prefix - it's not practical: too easy to overlook the files if you need to copy them.

As a general system: I cannot imagine a wiki.word with dots in between, as the dot for me looks too much like an object.property notation. As_the_underscore_somewhat_resembles_a_space (it separates individual words nicely) this was for me the logical choice. BTW, the underscore is only used when inserting a topic in an edit page - they are always rendered with spaces.

I also would not start a singleton _wikiword with a prefix underscore, because this would then be the exception to other wiki_words that always start with a character.

-- ArthurClemens - 14 Jun 2003

I like underscore more, because it's wider and easier to see - and is often used instead of space, what exactly we do here. Also, multiple times there were suggestions to alow hidden pages - and we can use unusual page name with _ prefix to indicate it's "hidden".

-- PeterMasiar - 18 Jun 2003

Peter, can you give an example of these kinds of hidden pages? What are they for?

-- ArthurClemens - 18 Jun 2003

WebSearch, WebChanges, WebNotify - pages which are for system use. When searching, usually you do not want them to show in results.

-- PeterMasiar - 19 Jun 2003

Arthur - about the use of SingletonWikiWordPlugin:

  • The page is invoked through the use of .Topic, but the topics on the filesystem are stored without the dot - e.g. as 'Topic.txt'.
  • I think the issues of singleton wiki words and spaces in wiki words are intrinsically separate
  • Adding a space to the end is not really intuitive - I would venture that prefixing the dot is more so, especially as it is a logical contraction of the Web.Topic syntax

-- MartinCleaver - 22 Jun 2003

One last argument for Singlewikiwordwithunderscore_ is that you can select it by double-clicking. .Singlewikiwordwithdot does not select the dot.

-- ArthurClemens - 31 Aug 2003

Arthur, your site is one of the few TWiki sites having a look that resembles a more commercial (read: non-technical) style. Could you update us with the current status of the skin and what kind of modifications to the TWiki source is neccessary for it to work? I can live without having underscore Wiki links and probably some other of your site-specific features as well. But the subtle clean look of the skin is attractive and gives the casual user the comfort of a "normal" web site while the advanced user still has all the TWiki powers available.

Is the skin in such a state that posting the source wouldn't be useful at all?

-- StefanLindmark - 14 Sep 2003

Happy New Year, Arthur. Just dropping by to check the status of your work with the skin.

-- StefanLindmark - 01 Jan 2004

CSS work

Arthur - I am contemplating posting a proposal to StandardizeTWikiCSSTags as one step towards ConsolidateFunctionalityFromSkins. Since I am hoping that PatternSkin will someday become the default TWiki skin and, having studied your style sheet, see that you have already developed a fairly complete CSS tag set, I would like to propose that your tag set provide the foundation this effort. What do you think of this?

-- LynnwoodBrown - 04 Jan 2004

The style sheet as is is quite a mess. I've mentioned it before, but this time I am making some work of it smile

So I am now in the process of refactoring the style sheets, to clean up the mess, to make it easier to override rules per web and topic. I am also reworking the templates. See some progress (untested on multiple browsers).

I am separating the style sheet in 2:

  1. pattern_base.css - defines the mark-up styles of basic style elements
  2. pattern_special.css - defines the mark-up styles of style elements that are defined in TWikiPreferences or the local WebPreferences, such as %STARTINTRO% and %STARTPICTURE%

Elements I've included so far:

  • pattern_base elements
    • body
    • p, td, ul, ol, ul, li, dl, dt, dd
    • h1, h2, h3, h4, h5, h6
    • :link, :visited, :hover
    • pre
    • strong, b
    • #bigseparator
    • #breadcrumb
    • .copybox
    • #copyright
    • #editbuttons
    • .hidden
    • #main
    • #topic
    • .twikitoc

  • pattern_special elements:
    • .comment
    • .excerpt
    • .introparagraph
    • .picture
    • #sidebar

This is for the view template only, there will be some more classes for other templates later on (next days).

-- ArthurClemens - 04 Jan 2004

Most excellent!! Thanks for the thorough and quality work!

-- LynnwoodBrown - 05 Jan 2004

Would you consider creating separate style sheets for printing, that set the sidebar to be non-visible so that most users wouldn't need to use the printable link? If you do I'd also suggest making the to bottom, to top and edit/print buttons non-printing.

-- SamHasler - 08 Jan 2004

Good suggestions.

-- ArthurClemens - 08 Jan 2004

Selecting parts of the NewPatternTestPage topic using the mouse produces some very strange results in IE. It doesn't start/end where I place the mouse. This isn't a problem in Firebird (0.7).

This seems to be a common problem with CSS and IE and is one of the reasons I've used it sparingly.

-- SamHasler - 16 Jan 2004

I see that text selection sometimes selects the whole text.

-- ArthurClemens - 16 Jan 2004

Once you get to the text "I should use some standard TWiki notation" it seems to select from where I click to the end of the page, and won't select before the start point if I move the mouse in front/above it. However it leaves some text unselected, see the attached image where I have tried to select the "S" of Sep.

-- SamHasler - 16 Jan 2004

SeeSkin has the same IE-Select-bug problem. Apparently the cure is a) to not use absolutely positioned divs, or b) force IE into quirks mode. More info at http://archivist.incutio.com/viewlist/css-discuss/35437

A workaround for the client is to Ctrl-Click which selects the whole paragraph.

-- MattWilkie - 16 Jan 2004

Arthur, would it be possible to remove the absolute positioning from #main? I've tried just removing it without defining any alternate possitioning and it seemed to fix the selection bug without affecting anything else.

  • I have changed #main to relative. Can't test it on IE Win from here, so quircks may appear. Mac IE 5.0 needs some work. -- AC - 20 Jan 2004
  • It does fix the selection problem but it leaves a large gap between the TOC header and the TOC as well as slowing down IE for some reason. The page renders and scrolls very slowly. I didn't have this problem when I just commented out the position: absolute; line. -- SH - 21 Jan 2004
  • Commented out position: relative line. -- AC - 21 Jan 2004

The anomalies when selecting the footer appear to be caused by the color: #999; definitions.

  • I think the bottom of the page needs some more thinking. I am not so happy that the attachment table is included in the footer style, so I will create a separate style for this. -- AC - 20 Jan 2004

I've also changed the background colour of the table below to make if more readable by changing "#eee" (which appeared as black) to "#d0d0d0". Do these colour definitions work on your browser?

  • Strange that #eee becomes black. Would #eeeeee work? -- AC - 20 Jan 2004
  • Yes it does. I chose #d0d0d0 so the table didn't merge with the DIV. I think TablePlugin must expect 6 characters. -- SH - 21 Jan 2004

-- SamHasler - 20 Jan 2004

"Commented out position: relative line."

This fixed the problem.

The large gap between the TOC header and the TOC appears to be unrelated. Using the following appears to fix it:

#main {
   left: 199px;
   width: 70%;
   top: 0;
   margin-top: 0;
}

-- SamHasler - 21 Jan 2004

Are you going to leave pattern_special and pattern_base as .css files or make them topics. The only concern I have is how big a performance hit it would for each topic. Apart from that it would be nice to have these under revision control.

-- SamHasler - 21 Jan 2004

When UsingTopicToDefineCSS makes it to the Core, I will make them topics (and for now for testing - I will post a note here). As they are linked from the header <style> within the template, view.cgi needs to extract %TEXT% from the topic, so I think that performance hit is neglegible.

-- ArthurClemens - 21 Jan 2004

I keep having problems with the main div. Either I set it to absolute, and I get text selection bugs, or I set it to relative, and then with resizing the page to small it snaps to under the left menu. Before I make it a table (which I prefer to not use for markup), can anyone give some advice/experience?

-- ArthurClemens - 22 Jan 2004

I tried making the sidebar absolutely positioned and the main div relatively positioned and that seemed to work.

pattern_base:
#main {
   position: relative;
   padding: 0 2.5em 0 2.5em;
....}

pattern_special:
#sidebar {
   position: absolute;
   left: 0px;
   top: 0px;
....}

I also stuck in some long preformatted lines and they were the only element that poked out at the right. Nice! Can't do that with a table.

-- SamHasler - 26 Jan 2004

This does not solve the text selection bug yet...

-- ArthurClemens - 09 Feb 2004

This is really excellent work!

I have a question to PeterThoeny: Is it possible to add at least format option for METASEARCH in the nearest TWiki beta release?

It woluld be useful when creating libraries' catalogs or thaught maps (see HowtoBuildThoughtManager).

-- AndrzejGoralczyk - 28 Jan 2004

Fixed the selection bug: somehow stating a width of 70% AND position: relative don't work well together. So I omitted the relative tag. When using right margins I get scrollbar problems.

pattern_base:
#main {
   width: 70%;
   margin-left: 224px; /* left bar width (200) + left margin of main (24) */
}

-- ArthurClemens - 09 Feb 2004

"Fixed the selection bug" Great!

The Print Version and Edit this page buttons are placed differently in IE and Mozilla. In IE they are above a left aligned heading; in Mozilla they appear on the same line, below the baseline, of a right aligned heading.

Welcome back Arthur.

-- SamHasler - 09 Feb 2004

Oh yes. Fixed that too.

-- ArthurClemens - 09 Feb 2004

Welcome back Arthur! I'm really (so patiently) waiting for a version of this I can try!

wink

-- MartinCleaver - 09 Feb 2004

Hi Martin, if you are impatient, you can download the files from this page. The links at the top table Work in progress get you to the live files. Of course now they are only a meagre view template with CSS.

-- ArthurClemens - 09 Feb 2004

I still have problems with Win/IE:

  • on loading the page I get an error
  • the width of #main causes a horizontal scrollbar to appear when there is a table on the page
  • text in tables is too large

Hmm, I'm going to take a look at CSS/flexible-layout.

  • Strange, the bugs descibed above only appear on Win/IE6 on my computer at home that runs ME. The page looks fine at my work box running Windows 2000.

    • Regarding the formatting bugs above, I updated my box from ME to Windows 2000 and the bugs have disappeared. -- ArthurClemens - 15 Feb 2004

-- ArthurClemens - 11 Feb 2004

Nice. However this page suffers from the IE selection bug. frown

-- SamHasler - 12 Feb 2004

Strange, the bugs descibed above only appear on Win/IE6 on my computer at home that runs ME. The page looks fine at my work box running Windows 2000.

-- ArthurClemens - 12 Feb 2004

I need my test server for testing for my day job, and I've now restricted topic view, requiring you to log in to view topics. Use TWikiGuest and duywkerhsu894has. This situation will last for about one week.

  • Correction: at least one more week. -- ArthurClemens - 23 Feb 2004

-- ArthurClemens - 14 Feb 2004

Could all the px sizes be changed to something that's more friendly to people with high resolutions and DPI. You might find the following link helpful (particularly the last link on that page):

which MattWilkie mentioned on VoidSkinDev. The discussion after the link on VoidSkinDev may also be of interest.

-- SamHasler - 23 Feb 2004

I've updated the dead links. On the test pages, don't forget to click on the "with skin" links if you do not see the left menu bar, otherwise you will get another style.

About the sizes: they are all flexible, so either:

  1. Change the view option in your browser
  2. Use a custom stylesheet:
    1. Create a topic with a style definition
    2. On the TWikiGuest user page, put: * Set STYLETOPIC = YourOwnStyle

for instance:

html body { font-size: 12px; } html>body { font-size: 12px; }

or modify CleanStyle topic.

-- ArthurClemens - 23 Feb 2004

http://www.dekko.nl/cgi-bin/extranet/view/Sandbox/NewPatternTestPage?skin=newpattern requests a username/password and TWikiGuest doesn't work.

try including the period at the end of the password

-- WillNorris - 23 Feb 2004

It's beautiful Arthur. I'm really looking forward to putting this through it's paces. smile

In "without css" mode clicking on 'skip to content' or 'go to menu' causes the page to reload with css (and no left-side menu).... oh hang on, all of the #anchor links do that. I seem to recall a bug filed about this in Codev awhile back.

  • That is because
    1. that template is lagging behind
    2. you should set a skin in the end to have it effective throughout -- ArthurClemens - 24 Feb 2004

in edit mode I see no reason for the large left/right margins; perhaps you anticipate putting something there later? I like 'add/change form' at the top instead of the bottom. I miss being able to save without previewing.

  • The edit screen is shown in div 'main', that has the same margins as the view page. I will make it wider.
  • The form at the top is for the extranet test. I am afraid that on twiki.org the forms are too high to put them at the top. For small forms the top is the better place.
  • I would like to have the direct save too. How? -- AC - 24 Feb 2004

I dislike the %STARTINTRO% blah blah %ENDINTRO% syntax. It would be better to use something like the following (a definition list item) which is much more readable and easier to type.

   Intro: blah blabbity blah blah
If that is just too general, prefix it with $Intro: or somesuch instead. If the regex was blind to "Intro", just slapping whatever word was found into the class statement, <dt class="ExecutiveSummary"> for example, this could be easily repurposed. A similar solution should be sought for picture-left|right as well. I can't think of a more editor-friendly alternative for COMMENT and COPYBOX at the moment.

  • Yes, we had a discussion on this a while back. But I wouldn't know how to implement this syntax. -- AC - 24 Feb 2004

in preview the text for 'go back twice for cancel' could be javascript to do exactly that . (I realise an argument could be made that it's better not to in order to force users to learn this habit). When previewing a topic which has STYLETOPIC set, the setting is ignored (probably not much you can do about this one, but it makes a liar out of the word "preview").

  • I will see how this can be improved. -- AC - 24 Feb 2004

view mode:

There is not enough difference in size between H5 & H6 (Mozilla)

  • OK, will check. -- AC - 24 Feb 2004

Unless the name of 'WebForm' is meaningful it should be ommitted from the table, otherwise it's just too cryptic. Example:

ProjectTitle: Dressing Up TWiki
ProjectCode: ArthurClemens
ProjectManager: a random passerby

I've been kind of ambivalent towards the idea of TOPICSTYLE, but now that I've tried it out I like it.

Great work Arthur!

-- MattWilkie - 24 Feb 2004

Added notes above.

I think there is a need for a top bar, such as in Monash University and http://www.juliediamond.net/cgi-bin/view/Know/WebHome. The other webs can go there, as well as search. I also like the "change text size" option from the Monash University.

  • Also the accessibility features of the Monash University look good.

-- ArthurClemens - 24 Feb 2004

How about ColoredWebLinks? smile

  • If you have good colours... smile -- ArthurClemens - 24 Feb 2004
  • The point is that they are the WEBCOLOR's, but I just realised that PatternSkin doesn't use %WEBCOLOR% variables at all. -- SamHasler - 24 Feb 2004
    • I was joking. Of course. This can still be build in, if this is easier than changing style topics. But it can be confusing to have color variables on different places. -- ArthurClemens - 24 Feb 2004
    • And now I realised that the reason you didn't use WEBCOLOR was because the CSS was in a static file. Once we can use topic to define CSS we will be able to use yucky WEBCOLOR's to our hearts content. smile -- SamHasler - 25 Feb 2004

-- SamHasler - 24 Feb 2004

Very, very nice Arthur. I'd love to see this installed as the default TWiki skin!

Only one comment; there's not enough contrast between a (default colour) unvisited link and the darker blue rows in tables. Konqueror browser.

-- CrawfordCurrie - 24 Feb 2004

I'm trying to test it, but edit does not have the preview changes / cancel edit area on it. can you pplease help?? - I also would like an optional header for the standard company banner smile

they are there right now for me (09:17p PST); a browser bug maybe? I tested using Mozilla 1.3a, Firefox 0.7, and IE5.5, all on Windows, and lynx on linux. -- MattWilkie - 25 Feb 2004

eeek - they are there on Arthur's site - sorry, they are not present on my twiki that I am testing the skin on (by copying the tmpl's and css's...)

I found a bug too. if the WebLeftbar contains some text that is larger than the bar is supposed to be, the leftbar stretches to accomadate the text, and comes up over the top of the main content. at worst, can we have it so the main topic is oabove the bar (z-order wise)?

-- SvenDowideit - 25 Feb 2004

Could the ampersands in the import url's be changed to "&amp;". Apparently "user agents will convert them back before following the links."

You may want to have a further look at: http://validator.w3.org/check?uri=http://www.dekko.nl/cgi-bin/extranet/view/Sandbox/NewPatternTestPage?skin=newpattern

-- SamHasler - 22 Mar 2004

I have changed the & to &amp;, also in TWikiPreferences (rss).

-- ArthurClemens - 07 Apr 2004

I just downloaded and installed over the top of my previous get the .tmpl files from 7Apr2004.

  • I changed the navlist div INCLUDE from WEB.WebLeftBar to MAINWEB.WebLeftBar as I want to define only one menubar. otherwise, when you create a new Web you need to go and confirgure again - this can be changed in the next release to have a WebLeftBar in the _defaultWeb that includes the MAINWEB.LeftBar by default
    • Should I use TWIKIWEB or MAINWEB? -- ArthurClemens - 08 Apr 2004
  • I am still missing the upload buttons on the attach page. (I have not looked into this)
  • rdiff output is still squashed up - i hope that i just have some unmatched html in my diff output)
  • i have changed #main to have margin-left:200px; and padding-left: 10px; (and no width) - i like it more on IE6 smile
  • there is a probalem if a wikiword in the sidebar is larfer than 200px - the sidebar extends over the main area frown
  • where are you listing all the id and class names that you are using so that we can code to them? smile
  • Can you commit the templates and stylesheets into cvs please? Then we can track changes as they are made.

-- SvenDowideit - 07 Apr 2004 - 21:17

Yesterday I started transforming the layout using flexible layout. This is tested more and built with more expertise than I can offer. The idea is to make it very easy to change the basic layout: 1, 2 or 3 columns, yes or no header.

The original CSS is made out of 4 parts, so I wanted to import them in the template using 1 style topic with the 4 includes in it. This does not work. Somehow only a part of the CSS comes through. Tonight I will have another look at it, but maybe I have to put all CSS in one topic.

I will maintain the flexible layout id names, and refactor the TWiki design class names.

I will put the files into CVS after the weekend.

-- ArthurClemens - 08 Apr 2004

I pointed out previously that flexible layout suffers from the text selection bug in IE. Please make sure you can fix that before you start using it.

-- SamHasler - 08 Apr 2004

- Hmm, I forgot. And I cannot fix the bug. I will return to my own code, seems safer.

-- ArthurClemens - 08 Apr 2004

- Has anyone contacted the authors of Flexible Layout to ask whether they know of the problem? -- MartinCleaver - 08 Apr 2004 - 16:04

I have a proposal for the naming of CSS elements of topic view. Please fire.

Naming and layout of CSS elements

-- ArthurClemens - 13 Apr 2004

Drop the TWiki prefix. it doesn't add anything except more typing. I'm not wild with CamelCasing the id and class names but I'll live with it.

-- MattWilkie - 14 Apr 2004

- Actually it does add something - it ensures all tokens are WikiWords. It is actually too broad though - these tokens are specific to FlexibleLayout or FlexibleSkin or FreeSkin or to the whatever you are planning to call the generalised CSS layer (i.e. ConsolidateFunctionalityFromSkins ) under PatternSkin.

-- MartinCleaver - 13 Apr 2004 - 18:41

Just to be clear, are you saying the prefix is necessary or the CamelCase? If the former, the prefix should be relevant, "Skin" or "Css" for example.

I haven't looked closely at how PatternSkin is developing, been waiting for a downloadable version to mangle, but your statement implies that each and every class/id/whatever is a separate wiki topic? please say no, that ain't so...

pretty neat trick that, replying a day before I wrote...

-- MattWilkie - 14 Apr 2004

Actually - the CssClasses that Arthur is talking about are in the TWiki Code (the PatternSkin is just the first to use it), and then will be used by any and all skins that use Css. So assuming that we want a namespace, the TWiki Prefix is the most logical.

-- SvenDowideit - 14 Apr 2004

About the prefix: this skin is developing to be TWiki's default skin. Using TWiki as prefix makes clear that the class is part of the default design. The classes can be overridden in topics, and new classes can be added locally, so a namespace distinction makes things clearly separate. If you want to use courier in the attachment table, you can write in a style topic: TWikiAttachments { font-family:courier }

About camel case: these classes are not meant to be separate topics. But I want the longer class names to be readable. And underscores are not allowed.

-- ArthurClemens - 14 Apr 2004

I'm pretty far with a basic CSS layout, and try to squash a few irregularities. But... I am getting the feeling that some cannot be solved because it is inherent to CSS block behavior on Windows explorer. The thing is, the majority uses Win IE.

Have a look at Three Column Layout with Equalizing Header and Footer. Now make the page very small, and look at the layout. This seems extreme, but on a TWiki site this behavior happens a lot more often if the topic title is long, or if there is a large image on the page (no problems when you use a normal browser though).

So the more I'm working with CSS layout, the more I am inclined to use a table instead of positioning divs. It is just so hard to get a column layout with header and footer that does not behave stupid, and that is at the same time flexible enough to let others change the layout without having to have a masters degree in CSS. If you look at the CSS source of the link above, and see the fixes that are needed to make it work across browsers, I cannot help but think that CSS layout has become the new religion.

Comments?

Added: compare div layout with table layout (ignore the leftbar in Mozilla)

-- ArthurClemens - 14 Apr 2004

On the prefix: I would advise using TWcssclassname rather than TWikiCssClassName, it is easier to type and manage (no need to remember if it is TWikiCssClassName, TWikiCssClassname, TWikiCSSClassName ...

  • But the style sheet will be in a topic, so you can always look it up. -- AC

On CSS, tables and divs, I will make a more documented post this afternoon

-- ColasNahaboo - 14 Apr 2004

- Why not make it a WikiWord? Surely these help documenting? -- MartinCleaver - 14 Apr 2004 - 04:47

- i personally don't like abbreviations, and you would need to look it up anyway. how else do you know if its TWikiCssClassName or TWWcssclssnm or anything else. saving typing is always a bad reason to make things less readable. always -- SvenDowideit - 14 Apr 2004 - 07:44 * CN I agree, that's why we never abreviate (omit wovels)

- You shouldn't need a prefix if you use the cascade: create a master [div id='twiki'] container which holds everything, then #TWikiTopBar becomes #twiki #TopBar {some-rule:10ex;}

this allows more flexibility; you can have another rule, say #coolskin #TopBar {other-rule:30%;}, which only takes effect if the skin is changed to coolskin (simply by changing the id of the master to container to id='coolskin' instead of 'twiki'). All in the same stylesheet even.

strictly speaking you could use body or even html as the master container ([body id='twiki']).

This kind of structure has been called Environmental Style. <== a much better explanation than mine. wink

maybe I misunderstand; is there some technical reason, a browser bug perhaps, which makes using the cascade unusable?

  • CN A readability reason: It just that it is more practical to understand the layout to see in the html a class=TWfoobargee and look for a foobargee definition in css files, rather than see a class=gee , and see all the definitions of gee and see which one apply in this context. But you are right, it is not strictly necessary.

Arthur you mentioned some irregularities: what are they? the page looked good to me in Firefox and IE6. I think the design has progressed far enough that a trip to the gurus at css-discuss is in order. They will (probably) have some cogent advice on how to fix things. I'm pretty sure I've seen a solution to the wide image pushing the block down in the page before. Save the test pages to static html somewhere and let the css-ers slashdot it.

ugh, I don't like CommentPlugin using BR instead of carriage returns. it makes it harder to refactor

-- MattWilkie - 14 Apr 2004 - 09:39

I've sent a mail to the css list. Part of the message:

One major problem is that the left bar is pushing the content of the main block down. You can see that with the large image, and with the attachment table in wtable.html. It also happens with tables in the content block that have a width of 100%. So I've set the width of div #TWikiTopic to 99% for IE. But obviously that does not solve everything. The forcing down of the content also happens when you minize the width of the browser window. It happens too when the page has a long title (and Wiki names can be quite long without any spaces).

I also have some problems in getting the tool bar at the top layed out nicely, but that is a minor issue.

-- ArthurClemens - 14 Apr 2004

Hurray! Found the solution, by myself after another round of trial and error! Set the left bar to an absolute position and all works well!

The minor downside is that now the position of the left bar must be set explicitly, so together with the top bar height skin authors have to update 2 variables. But anyway better than tables or forced down content!

-- ArthurClemens - 15 Apr 2004

- Congratulations Arthur! updating two variables isn't so bad. -- MattWilkie - 15 Apr 2004 - 21:47

Added some reply here, and a page to expose the LongLinesLayoutCssProblem

-- ColasNahaboo - 16 Apr 2004

The first templates and css are now in plugins CVS. Note that this is still a work in progress.

-- ArthurClemens - 16 Apr 2004

I've updated the layout. See PatternSkinTestPage, name/pw below.

Comments are welcome.

-- ArthurClemens - 19 Apr 2004

- looks good Arthur. There is some weirdness with Firefox/Win v8 in that only the H1 resizes with ctrl-plus/minus until I get to +4 or +5.

the very long pre line problem is something I've wondered about for quite awhile. I think twiki needs to manually wrap at some point. I predict it will be a long discussion. ;)

I would change the LI's in the left menu to be in/out-dented or otherwise demarked so that wrapped links are recognisable as a single item (without having to hover).

I'm starting to play with the cvs version. It's a plus that out of the box there are helpful "this included template topic is not created" messages along with a link to create them. Very intuitive.

I'm not wild about the fixed width left bar (too wide for me) but I perfectly willing to change that myself for my own site.



-- MattWilkie - 20 Apr 2004 - 12:41

Thanks, Matt

  • I will check the FireFox. Is it only this page that gives a problem, or other sites too?
    • figured it out: there is a config option in FF to set the 'Minimum Font Size', which I have set quite a bit higher than your default. -- mhw
  • left menu: I will try to makes this clear, hopefully without having to use indenting as this takes quite some screen estate

Next step:
Separate layout from style, so they can be changed independently, analogous to MovableType's styles and templates. So there will be 2 default style topics and 2 custom style topics:

  • TWIKILAYOUTTOPIC: TWikiLayout
  • TWIKISTYLETOPIC: TWikiStyle
  • LAYOUTTOPIC: CustomLayout
  • STYLETOPIC: CustomStyle

Then it would be nice to have a style generator that fills in values, for instance if you choose a line color and width it inserts these at the right places (future release).

-- ArthurClemens - 20 Apr 2004

D'oh, i thought you were checking it into the twiki cvs, as it is going to be in the default package smile

as far as testing goes - when I set the pattern skin, my edit and preview pages have no buttons. this means that I can't use it yet frown

-- SvenDowideit - 21 Apr 2004

Of course, now there is only the view template. That is taking me a lot of time - I hope the rest will go a bit faster. I have now made the page accessible for browsers without CSS. It functions properly on Netscape 4.79 (tested).

Because I have changed the setup of the templates in twiki.pattern.tmpl, the other templates are 'broken'. I am trying to get a better separation between module definitions and module calls. This is what each page should do:

%TMPL:P{"htmldoctype"}%
%TMPL:P{"head"}%
%TMPL:P{"bodystart"}%
%TMPL:P{"main"}%
%TMPL:P{"bodyend"}%

Each template will redefine module main, some will redefine head.

As soon as edit, preview and attach work, I will put this skin into the main CVS.

One thing that still bugs me is the incompatibility with TablePlugin settings. If cellspacing="1" is defined, all tables will have a border, no matter the css settings. So if you use pattern skin, you must set tableplugin values to zero.

-- ArthurClemens - 21 Apr 2004

- Ok Arthur - if you want help - just tell me wht to do smile there are a few of us waiting to see how it turns out (and our managers are already drooling) -- SvenDowideit - 21 Apr 2004 - 04:20

Of course help is welcome!

Can you understand/read the module setup in twiki.pattern.tmpl and view.pattern.tmpl? First, there should be created pattern variants of other base templates: edit.tmpl, preview.tmpl, etc. These templates should mirror the module naming and order of twiki.pattern.tmpl and view.pattern.tmpl, and override only where necessary. It is possible that in twiki.pattern.tmpl the modules need to be further refined. For instance the module head had a base href in it that is perhaps the only element that changes with each base template. So possibly base href should be in a separate module that can be overridden.

In contrast, main module is quite large because that one is so template dependent, with a lot of changes every time.

To summarize, you can start to copy the setup of twiki and view for the other base templates, and change them where you find necessary.

-- ArthurClemens - 21 Apr 2004

- I have made simple refactorings to the other templates that we need for the pattern skin, and commited it into the twikiplugins cvs. feel free to fix my bugs smile but Arthur will need to re-work them to improve the usability. -- SvenDowideit - 08 May 2004 - 05:03

- I had a problem with checkboxes not being visible, and fixed it (i don't know if this is the right way thought) by removing input.height:100% from base.css

I have not commited this change though -- SvenDowideit - 12 May 2004 - 01:46

found reason for Moz FF text not resizing right away; comment inline above -- MattWilkie - 11 Jun 2004

I am getting the installation back again on my test server: http://www.dekko.nl/cgi-bin/projects/view/Sandbox/PatternSkinTestPage. I see some minor css bugs in the attachment table that I will fix tomorrow.

I am leaving out local style definitions (STYLETOPIC etc) because of performance problems that are still not solved, so back again to linking to the pub/skins dir.

See also another skin I have been working on: http://www.dekko.nl/cgi-bin/projects/view/Sandbox/PatternSkinTestPage?skin=projects

-- ArthurClemens - 15 Jun 2004

Hi Arthur, I just committed some draft topics into CVS which should help developers get up and running with the skin. Please feel free to completely overwrite them. When the test site went down and you were not around for a couple of months I thought maybe life had intervened. smile I based the sample side panel on the Patterns Repository, not your current site (because I couldn't get to it).

-- MattWilkie - 15 Jun 2004

- I have just commited the template files into Core TWiki SVN.

personally i think its interesting to see what the skin looks like when there's no base.css too - see http://ntwiki.ethermage.net/users/sdowideit/cgi-bin/view?skin=pattern

-- SvenDowideit - 23 Jun 2004 - 23:12

I am resuming work on Pattern Skin. Hopefully I can get some work done before the release of Cairo.

-- ArthurClemens - 21 Jul 2004

- um, there are restrictions for me -- SamHasler - 21 Jul 2004 - 17:11

Sorry, forgot to update .htaccess.

-- ArthurClemens - 22 Jul 2004

- Where can I find the *.css files? I have an ancient copy from the web somewhere, but I don't think they are current and I can't seem to come up with them...

-- BruceDillahunty - 22 Jul 2004 - 20:05

I have updated the table above, with a link to the css.

-- ArthurClemens - 23 Jul 2004

Thanks, much better smile

Now, could anybody give me a pointer to what I need to change to make a table look as nice as a form? The forms look just great, but the tables look about the same... I don't speak *.css, but I imagine I could figure something out if somebody points me in the right direction. I see there is a table section in the *.css, and changing things there do affect it somewhat, but I don't know what variables it "knows about". Thanks!

-- BruceDillahunty - 25 Jul 2004

Bruce, do you mean ordinary tables in the topic? Created with pipe (|) characters? These are not touched by pattern skin css. To change these, go to the topic TablePlugin in your own TWiki web.

- - - - -

  1. I am working on attach pages. There is a bug in the alpha release (the attach table won't show up), so I reverted to the latest alpha release. Update: Test site is now up to date with Subversion. Table now shows up thanks to attachtable.tmp. Pages not yet tested on windows.
  2. I can't get subversion yet to work, so all pattern skin changes (templates too) are in CVS only. Pattern skin in CVS will be phased out soon.
  3. I think I will give the attach table and form on the view page a lighter (white) th.
  4. I changed all ids to classes, to support multiple class names. See CssClassNames.

-- ArthurClemens - 25 Jul 2004

Yep, those are the tables I meant... thanks for the pointer... I think I've got that going now smile

Just for my education, why is the attach table such a separate beast from standard "tables"?

  • I want to prevent that the attachment and form tables are just sort of bungling at the bottom of the topic. I find their current layout quite distracting. I want to have a separation between topic text and other (supporting) blocks like the topic action buttons and these tables. It should be clear in one glance what part of the page belongs to what. So these tables should have other colors than topic tables. -- AC - 25 Jul 2004

Thanks for all your work on this!

-- BruceDillahunty - 25 Jul 2004

I've updated the table at the top with attachment templates. Not finished, but quite underway.

-- ArthurClemens - 25 Jul 2004

FYI, I think the link to the *.css stuff is broken again... matter of fact, most of them were... I fixed them (I think they are pointed right now... might want to double check that I got what you really meant.

-- BruceDillahunty - 26 Jul 2004

Yes, thanks, I was tired I guess.

-- ArthurClemens - 26 Jul 2004

I probably just goofed something up, but I'm back to the left side bar taking the entire width of the page, instead of just over on the left... had this problem before, but the base.css fixed it... with the new stuff its back... what did I mess up this time? smile

-- BruceDillahunty - 26 Jul 2004

Bruce, can you check the "Release edit lock" when you save? Then I can react sooner.

  • Wilco, sorry. -- BD

The base.css in not in use anymore. But the problem is all templates and style sheets are in heavy revision progress, so it would be better if you wait for a few days and then try again with the new (final) stuff.

Change: Changed all tags starting with "TWiki..." to "twiki..." to enable multiple class names.

  • OK, I'll keep an eye on your progress... thanks again. -- BD

-- ArthurClemens - 26 Jul 2004

Just in case it helps anybody, I found my problem... I missed the change of the pointer to the style pages to be TWIKILAYOUTURL, TWIKISTYLEURL, USERLAYOUTURL and USERSTYLEURL

Looks much better now smile

Thanks again.

-- BruceDillahunty - 27 Jul 2004

-- ArthurClemens - 28 Jul 2004

"Cancel edit" on the preview page doesn't have ?unlock=on in the url.

  • It has now. Thanks for the notice. BTW, is there a shorthand notation to add a param to square brackets notation? -- ArthurClemens - 29 Jul 2004

-- SamHasler - 29 Jul 2004

More templates are ready:

  • preview
  • changeform
  • oopsmore

-- ArthurClemens - 29 Jul 2004

Regarding wrap in textarea tag, this is to support ancient Netspace which would scroll all text of a paragraph horizontally on one line if not present. See examples at http://www.utexas.edu/learn/forms/boxes.html. I suggest to address this after Cairo.

-- PeterThoeny - 31 Jul 2004

General comments and progress reports

moved discussion from CoffeeBreak:

Hmm, when I try ?skin=pattern I just see the sidebar; the body text is below the "Last changed" line. This is on IE 6 and NS 4.

  • OK, found out that the missing TWIKILAYOUTURL and TWIKISTYLEURL settings are the culprits.

Could the supporting topics for pattern skin be named so that they can be identified as such? Also, split up pattern skin specific and generic skin settings in TWikiPreferences, and name the settings accordingly. Could be named for example PS_TWIKILAYOUTURL, PS_LAYOUTTOPIC, etc. ClaussStrauch did that nicely for the DragonSkin.

  • In SVN I have updated references to the topics. When syncing, these topics should get renamed in the file system, not with Rename:

  • The idea was that the default skin could also use these settings, therefore the variables have a generic name. See UsingTopicToDefineCSS. -- AC
    • Sorry, I was not specific enough. It is good to raise the bar and supply more infrastructure to different skins. So if you intend to declare WebLeftBar a TWiki standard keep the name; if you consider this PatternSkin specific, name it TWiki.PatternSkinLeftBar. -- PTh
      • To make something reusable was the idea. I also use twiki css class names. Discard my previous remark about renaming. -- ArthurClemens - 01 Aug 2004
        • One issue is left though: If used generically, content should not get duplicated. The WebLeftBar duplicates the WIKIWEBLIST and WEBTOPICLIST settings which is confusing and gets out of sync easily. It also does not allow web links defined per web (as used here on TWiki.org for example). The SEP setting (default is pipe) can be redefined; skins can set it to something else, e.g. bullets. At my workplace all skins use the WEBTOPICLIST, but redefine the separator. -- PTh

Could some minimal support be done for NS 4? For example show the sidebar next to the body text (like DragonSkin), or even below the body text to bring out out of the way...

  • I will look into older browsers after Cairo. But I cannot promise anything for NS 4. NS users can always use the default (Classic) skin. -- AC

The sequence of the save buttons should be aligned. I just hit Cancel instead of Save after changing skins. I find Preview, Save, Quiet save, Cancel a natural sequence (logically (to bypass Preview jump over it to Save) and by frequency of use)

  • The Cancel should be positioned at the left, because it has a similar function of going backwards. The OK button (or Save) should be at the right of the Cancel button to indicate progress. These positions are not negotionable smile So I stick to the Apple UI Guidelines that I find better than Microsoft's Guidelines.
    The buttons for QuietSave, Checkpoint and Preview can be switched (for instance, all Save variations next to each other). I preferred to highlight Preview and Save (darker color) because I presume these buttons will be used most, and the others are secondary.
    But I can change the order of the default skin to bring this more in line with pattern skin.
    by frequency of use - You should always look for improvements smile -- AC
    • You are the usability expert, it is your call. Yes, align the classic skin with the pattern skin. -- PTh

-- PeterThoeny - 31 Jul 2004

grayed out part: see summary below -- ArthurClemens - 01 Aug 2004

I have added (SVN) an anchor link at the end of the topic, and changed the top link "to bottom" to "end of topic". Especially with long twiki forms you had to scroll back to read the last entry. See example.

I have set up a test page PatternSkinExampleBlueStyle. But it does not work. Peter, is the file twiki.pattern.tmpl the same as in SVN?

Well, this is the idea.

-- ArthurClemens - 01 Aug 2004

Issues, sorted in order of how irritating they are (1 == extremely irritating)

1. On my browser the left bar in view is approximately twice as wide as the text contained in it, wasting a huge amount of screen real-estate that would be better used for content. It also doesn't get narrower when the window is narrowed; surely it is less important than the page content?

  • I have put it in the bugs table above. Could you have a look at the attachment to see if this is different than with you? -- ArthurClemens - 01 Aug 2004

2. Possibly just my browser (Konqueror) but PatternSkin on TWiki.org is painfully slow (several seconds to fully render a page). Contrast with DragonSkin which is as fast as the default skin. 3. I don't know if it is the skin or something else generating it, but in my leftbar it has "TWiki subsites" above the list of webs. Subsites? Where did this terminology come from? Why has it been introduced? Where is it explained?

4. Why is Save so far from QuietSave? The two actions seem to me to be very similar. Surely:

Cancel Preview Checkpoint QuietSave Save

5. The link "Print Version" at the top of the page (and in the bottom bar) I would immediately interpret as "print this page" and not "show me a printable version". Just "Printable" would be better. 6. The AccessKeys link should use the launchWindow function to open in a separate window, like all the other help. 7. When viewing WebChanges the pink table header overlaps the navigation links at the top of the page, making "version" look highlighted, which confused me momentarily.

Apart from 1 and 2 these are really just nit-picking. The skin generally looks super! But 1 and 2 are really quite irritating, and would stop me from deploying the skin.

-- CrawfordCurrie - 01 Aug 2004

I formatted the TWiki.PatternSkin topic according to the skin template. Arthur, could you create the two screenshots?

-- PeterThoeny - 31 Jul 2004

Changes and opinions (involving discussion above). See also the bug table above.

  • OK, found out that the missing TWIKILAYOUTURL and TWIKISTYLEURL settings are the culprits - the switching to pattern skin should be improved. I am currently looking at a solution. The variable settings should be turned on by default, so you only need to append ?skin=pattern to see the new skin.
  • Could the supporting topics for pattern skin be named so that they can be identified as such? - After deliberation and switching my opinion a few times I have come back to my original idea: pattern skin is mean to be the default CSS based skin. Newly developed skins can fall back on the base layed out by pattern skin, and can focus on really changing appearance only (no development of new templates necessary) by creation new css files. Something like with Movable Type. This means that included topics such as WebLeftBar are skin independent. Conclusion: topics names should be kept as is, but use of these topics should be documented.
  • Could some minimal support be done for NS 4 I am still running hard to make all changes, fix the most important bugs, write documentation, so I need to leave support for older browsers after Cairo.
  • The sequence of the save buttons should be aligned - I have updated the layout according to the latest suggestions (good!) in the edit template for both pattern and classic. I will also update the order of links in the oops templates soon.
  • Print Version - this is probably my non-native English background. Printable is fine with me.

If you don't see any of the changes: wait until twiki.org is synched with the latest SVN code, or check the test site (upper table).

  • Speed. Question: how can I perform profiling tests?
  • Did anyone check out the diff pages? What do you think?

-- ArthurClemens - 01 Aug 2004

I'm curious, will the "attention", "picture", "excerpt" and "relatedbox" classes from the formatting css file at visiblearea.com somehow be a part of the PatternSkin also?

I find them very useful (especially when layed out as TWikiVariables, of course) - but I haven't seen any notice of whether an inclusion in the PatternSkin is going to happen? You definetely have my vote in favor.

I agree that the left bar is a bit on the wide side currently, especially in resolutions 1024x768 and below. For resolutions 1280x1024 upwards it seems acceptable.

But I guess that (at least in my workplace) 1024x768 is still the common denominator, so my feeling is that we'd go for downsizing the left bar a bit if it is not made any narrower in the final release.

  • Have you noticed that the width of the sidebar is dependent on the font size? Scale down the font and the left bar shrinks too.
  • I will take some screenshots of other sites to make comparisons easier. -- ArthurClemens - 01 Aug 2004
    • Problem might very well be be, that we are not too useability-oriented at our place - I guess we like the size size of the slashdot menu too much (PatternSkin in comparison). -- SteffenPoulsen - 02 Aug 2004
      • Haha, yes Slashot is not the prime example of usability! The menu is not very realistic, because their menu names are very short and that you cannot predict in advance for other installations. In fact, the current menu items are very short - this will probably get longer, especially when parent/child navigation is included. -- ArthurClemens - 02 Aug 2004

-- SteffenPoulsen - 01 Aug 2004

CSS can be defined by topic or by attachments. This raises the complexity and is not KISS. What is the rational to support both? Possibly simplify? For users it should be very simply to enable and configure a skin.

  • CSS by topic makes it easy to make local overrides per web or per user. Not necessary for default installation. I will make this more clear in the documentation. -- ArthurClemens - 02 Aug 2004

-- PeterThoeny - 02 Aug 2004

Current performance, build 1665.

Browser Skin Requests per second
Konqueror Default 1.6725
Konqueror Pattern 1.4625
-- CrawfordCurrie - 02 Aug 2004

Crawford, what does this mean? How can I perform this test myself? For instance with and without style sheet?

-- ArthurClemens - 02 Aug 2004

Some small changes (SVN):

  • Fixed pixel spacing bug in Explorer in attach table and form table (I have added attachtable.pattern.tmpl)
  • Added css support for checkboxes in templates (.twikiCheckbox)

Peter has updated TablePlugin, so sorting does now work (visually).

Some things in DragonSkin I find appealing that I would like to include too:

  • subtle use of BGCOLOR variable (although the colors themselves are not so nice)
  • "you are logged in as..." - but this would need a login/logout possibility, so I will wait with this.
    • i've collected the current list of topics related to this at CategoryLoginLogout. there's some testing work at HowToLogin. also, i created TWikiGuestLeftBar in the hopes that this would work as the first step for logging in (i haven't been able to test it because twiki.org remembers me wherever i am wink -- WillNorris - 02 Aug 2004

-- ArthurClemens - 02 Aug 2004

Restored:

Comparison table for left nav width:

Screenshot Site Width Content varies?
leftbar_slashdot slashdot.org 92 Not
leftbar_apple apple.com 180 Some
leftbar_oreilly oreilly.net 167 Some
leftbar_wired wired.com 269 Much
leftbar_movabletype weblog.delacour.net 202 Much
leftbar_patternskin twiki.org 193 Depends

Of course the functions of these menus vary wildly. Some sites have menus that won't change much (Slashdot, Apple), others that will change every few days with possibly long links titles (Delacour, Wired). Sites with varying (longer) menu items tend to have wider left bars (surprise?).

For twiki it depends if you want to put topic names in the left menu or not. The current menu has short topic names, so indeed for that purpose the menu could be smaller.

On my test site I have changed the left bar width from 16em to 14em. And I have added a few longer topic names to the menu: http://www.dekko.nl/cgi-bin/twiki/view/TWiki/WebHome

This brings up an interesting question what should happen to menu items that flow out of their box. Use overflow:hidden to hide them? (Again a reason for me to use spaces in topic names, or use spaced wikiword plugin).

See for an example of overflow: http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/TopicIncludingOverflowStyle

-- ArthurClemens - 02 Aug 2004

Arthur, I saw your comment earlier today on different menu sizes and different uses from various sites, and the use of overflow layouts related to this etc - but the comment unfortunately seems to be gone now (only the screenshots are left below?)

But I had a thought - why not take a "best of both worlds" approach, and

  1. Let the users expand the width of the menu as needed (you're right about hierachical webs etc - long items are bound to show up at some point)
  2. Simply let the users who prefer not to gaze at a wide menu all the time, just "hide it" temporarily (toggle it on or off as needed).

There is an example of what I was thinking, at http://www.thetoxiczone.com/programming/javascripts/tv.aspx - I have no idea whether this breaks any CSS / Javascript / crossbrowser / usability / etc-etc issues with PatternSkin, but for our way of working at our site this might be a winning compromise.

With a menu like this, you can have all of your screen real estate in use as/when needed (as an example we use a lot of pictures and sketches in our documentation, so we often get the horizontal scrollbar in 1024x768 - this could in some cases probably be avoided by toggling the menu off momentarily), or you can have a large and clear menu when needed.

Am I in the woods here? -- SteffenPoulsen - 02 Aug 2004

I think this can be useful. A few points to think about:

  • This does not solve the problem that some people have about having a 'wide' menu. Because if you hide the menu you cannot use it. It does solve the problem you describe: some pages need all space they can get. You can also choose to create a USERLAYOUTSTYLE topic with css to hide the menu, and include that in each topic where you want to hide the menu. See example: http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/TopicWithHiddenMenu.
  • The javascript approach:
    • If you completely hide the menu, the button to hide it (and show again) should not be in the menu (but where?)
    • If you minimize the menu, a small image (triangle?) can be used to make the menu small and wider.
    • If you have the control visible (show/hide) you are going to expect to keep the state if you go to another page. So you would need to work with a cookie to remember that state.
    • The necessary javascript is simple enough to run on almost all browsers.

-- ArthurClemens - 02 Aug 2004

I keep forgetting just how much this skin can be configured just by using topics, it's simply excellent.

You make good points. I wouldn't mind delaying the pursuit until after CairoRelease, so that they can be given more than a minutes thought.

A minimal subset of the the above could be a simple "full width for content" button, that would work only for the current page (currently viewed instance of the page), and would leave the user no opportunity to bring back the left bar (except for pressing F5 / doing a refresh). This would avoid the cookie/state issue and the logic/design concerning bringing back/resizing the menu. Perhaps this could even be configured "locally", i.e. in a (site-wide) css-style-topic?

-- SteffenPoulsen - 03 Aug 2004

for a customised sidebar for a guest or for the unlogged in state, create/edit Main.TWikiGuestLeftBar

It may just be my settings, but I get really wierd behaviour when editing using IE.

The edit page opens up normally, with an edit box that fits nicely in the display area. As soon as I type a character it shoots out to overlap the right edge, so I lose sight of the scrollbar. Annoyingly, the horizontal scrollbar that you would expect doesn't appear. So you end up with an edit screen that has the first third blank grey space, two thirds of an edit box, and another third of an edit box invisible off the end of the browser and no scrollbar to get to it.

I'm editing on twiki.org, BTW. My personal settings are visible in CrawfordCurrie.

  • I have seen that too since today. Of course I would have noticed if this was from day 1. But its hard to track down where this behaviour suddenly comes from. If I remove style="%EDITBOXSTYLE%;" it works ok, but the textarea becomes too small. Looking up in Google I found this page: http://fplanque.net/2003/Articles/iecsstextarea/. Taking these tips I have made a fix, now in SVN. Now only wait when it will show up in twiki.org. You can test it on the test page. -- ArthurClemens - 03 Aug 2004

Everything is fine under Konqueror (except for the wasted space down the sides, that is!)

  • I would have created a bad general design if the content was stretched to all sides. For you personal preferences you would need to override or modify the base style. -- ArthurClemens - 03 Aug 2004

BTW apologies but I've cracked; even though I'm only testing, the big grey bar on the left of the view is driving me nuts. I can't work out how to hack the templates so I'm switching to DragonSkin.

  • Huh? The left bar in DragonSkin is wider than PatternSkin! -- ArthurClemens - 03 Aug 2004
  • Not on Konqueror; left bar in dragon is the width of the text. On Pattern it is twice the width of the text (approx. 22% of the screen width) - -- CrawfordCurrie - 03 Aug 2004

Browser Dragon Pattern
Konqueror dragon.jpg
Win IE 6 dragon on Win IE 6 pattern on Win IE 6
Firefox dragon.jpg

-- CrawfordCurrie - 03 Aug 2004

Looks like Konqueror has a differnent opinion on rendering the page, making the table too small in dragon and too large in pattern - in comparison to the browsers I have tested on. Because in Explorer (or Mozilla) its a different story, see updated table above.

I can also see you have your font quite large. If you shrink the font size, the left bar should shrink too.

I have made the left bar a bit smaller in the meantime (14em now).

-- ArthurClemens - 03 Aug 2004

Arthur, could you add the %BROADCASTMESSAGE% somewhere on top of the skin? See also BroadcastMessageHandling.

Also, the pattern skin's sidebar is enclosed by a form with action bin/search. Can we get the GoBox back for CairoRelease? In DakarRelease we can address GoIsSearch, then we have search and go functionality. For consistency I believe it is better to offer go functionality in Cairo.

-- PeterThoeny - 04 Aug 2004

OK, OK, so it's Konqueror. I've tried IE and Firefox as well, and well, read my lips, THE LEFT BAR IS TOO WIDE. IMHO it should be no wider than the text it contains (with appropriate right margin of course).

In the course of my career I moved from VT100 to CGA to EGA to VGA to XVGA, each time getting slightly less frustrated with the amount of text I can get on a display. Now, just when I have 1024X1280, you want to take a huge chunk of it away again!

When I size down a browser so I can have several side-by-side (as I do often when cross referencing between - say - help info and text, each of the two browsers is dominated by the left bar - wasted space.

A perfectly valid option would be to let me close down the left bar, in the same way as most browsers allow you to have a closeable history bar on the left. But an equally valid and simpler solution would be to MAKE THE LEFT BAR NO WIDER THAN IT ABSOLUTELY HAS TO BE!

A love the look of PatternSkin; but this is a real problem for me. A killer.

P.S. I use larger fonts in browsers because as my screen resolution has gone up, my eyesight has gone down frown

-- CrawfordCurrie - 04 Aug 2004

that's curious. When I'm using the 'edit styles' bookmarklet (http://www.squarefree.com/bookmarklets/) the @imported stylesheet is a complete html page not just css. A bug for sure, but in the marklet or in twiki?

  • I haven't had the time to look into it. What does the bookmarklet do? How do you integrate it with TWiki? -- ArthurClemens - 05 Aug 2004

-- MattWilkie - 04 Aug 2004

Just a quick note of acknowledgement for both the quantity and quality of work you've been putting into PatternSkin! I've just turned it on for twiki.org and - wow! - what a treat. Clean, readible, and completely first rate. This is a major, major asset for Twiki and a great foundation for further skin development.

  • Thanks! -- AC

-- LynnwoodBrown - 04 Aug 2004

in layout.css changing under .twikileftBar

position: relative;
width:auto;
top: 0px;  
and adding:
float: left;
and changing under .twikiMain:
margin: 0 0 0 1em
lets you recover some space on the left. (konqueror and mozilla)

-- MarcelTrap - 04 Aug 2004

Changes in SVN:

  • Web indicator: a small line at the top of the left bar
  • Go box for left bar and top bar (have to decide which one is final)
  • Many small Explorer 5.0 and 5.5 fixes
  • Made the signature text an input field: easier copying

  • Added teamwork logo for try out

If you want to hide controls (topic actions): http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/NoEdit

-- ArthurClemens - 05 Aug 2004

How do we let users know the name of the topic and what web they are in? (noting that %INCLUDINGWEB%.%INCLUDINGTOPIC% was pulled from WebTopBar)

  • You will be forced to add a title to each topic! smile
  • I have changed the top bar a bit - although the layout is a bit messed now because I have changed to classnames, have to wait until twiki.org is updated. -- ArthurClemens - 05 Aug 2004

Also, I too have problems with the real estate taken up by the side panels (but am willing to wait for the other pattern skin things to settle out before I start trying to change them, possibly with user-preference css overrides).

  • Already some topic names are too long to be in the left bar, so they are clipped. I cannot go smaller. But if you change them personally: I am now writing the css documentation.

-- MattWilkie - 05 Aug 2004

I have made a change (again, but almost(?) final) to the topic name. Because I was not so happy with the crowdedness of the top right with the go box. See my implementation at http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/PatternSkinTestPage. Change is in SVN, and I have removed the topic name already from WebTopBar.

-- ArthurClemens - 06 Aug 2004

I agree with you, that it's a good idea to have the topic name close(r) to the content. But the new position quirks my eyes - how about something like this instead?

Minor layout suggestion

I know that suddenly this is two lines instead of just one, but that would be my preference. Our topic names can be / tend to be (very!) long, so it'd actually be nice to have a line more or less just for that piece of info.

Btw: I like the new layout of the signature-box - very intuitive!

-- SteffenPoulsen - 06 Aug 2004

Hi Steffen,

For the past 2 hours I have been shuffling the toolbar elements around and around to find an optimal presentation. In the end I wasn't satisfied with the default double line at the right, because this lead to a larger gap above the title, leaving a bit awkward white space across the screen. Now I have tried to solve it by using shorter copy. On a 1024x768 screen there is now quite a bit of room for the web.topic name. I also improved the way the text wraps on a smaller screen or with longer topic names. And I removed the link from the author name to not clutter the top with too many links. The link to the author's page is still at the bottom.

  • In default Internet Explorer 6 settings (medium text size), your test page wraps the top line in 1024x768 at the moment. So it seems that the two lines is going to be the case anyway, the line will be shown wrapped for most topics in 1024x768/default ie. If so, I think two crafted lines looks better than one line that wraps. -- SteffenPoulsen - 07 Aug 2004

Again, see my test page.

-- ArthurClemens - 06 Aug 2004

i like it alot too smile One thing, one of the guys at my work would like to see the breadcrumbs back at the top. is there any nice way you can work that back in? (though i'm more worried by the huge amount of things up there above the topic)

-- SvenDowideit - 07 Aug 2004

The reason I have left out the breadcrumbs (I had them in my original pattern skin) was indeed the crowded top. Usability research shows every time that breadcrumbs are hardly used. I do think they have their occasional use, so they are at a page (the bottom). I think they are more useful when showing search results. For instance go to http://www.annefrank.nl/werkstukwijzer/ and type in the search box "Anne". Here each hit shows where the page belongs, and that makes it easier to differentiate. But not many TWiki sites will have their topics so thoroughly parented.

I need some help: For the personal link block of the WebLeftBar, I have put an edit button in WebLeftBarPersonalTemplate. This template is called when clicking on Create in WebLeftBar. But in the template the username-topic (f.i. ArthurClemensLeftBar) is already expanded while it should stay a variable.

%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%%TOPIC%%?t=%GMTIME{"$year$mo$day$hours$minutes$seconds"}%

TOPIC need to stay TOPIC.

  • This works OK? TOPIC stays TOPIC and the "edit" link in the personal bar (after it is saved) will edit <username>LeftBar. Was your intention for the link to be a link to edit the currently displayed topic instead, or? -- SteffenPoulsen - 07 Aug 2004
    • i intended it to edit the personal left bar topic -- WillNorris - 10 Aug 2004

-- ArthurClemens - 07 Aug 2004

This is really hard for me to test and/or work on; i've had to do a lot of the WebMenu work blind because i can't get twiki.org to forget who i am!

  • This one is easy - in Internet Explorer, just close all browser windows, and when you start the browser again, just authenticate as TWikiGuest/guest at the prompt (i.e. when pressing edit). Close all browser windows again and start over. -- SteffenPoulsen - 07 Aug 2004

-- WillNorris - 07 Aug 2004

Question: to let WebLeftBar be web-dependent, I could eiter:

  1. In twiki.pattern.tmpl include %INCLUDE{"WebLeftBar"}% instead of %INCLUDE{"TWiki06x00.WebLeftBar"}%. This means that this topic should get created in every web (but that is what we want)
  2. Change TWiki.WebLeftBar to TWiki.TWikiLeftbar, and put %INCLUDE{%INCLUDINGWEB%.WebLeftBar}% in it, so webmasters can choose if they want to have 1 global left bar or a left bar per web.

Pro 1

  • simple design, easy to understand
Against 1
  • restrictive, because you must create a webleftbar for every web

Pro 2

  • easy to have 1 sitewide left bar
Against 2
  • step-wise design, so possibly confusing
  • possible performance loss (is it?)

I would go for the simpler design (1) but there may be other arguments.

-- ArthurClemens - 07 Aug 2004

No. 1 sounds great by me.

-- SteffenPoulsen - 07 Aug 2004

this was the first thing i changed. I prefer the look and feel to be the same where-ever you are, so at work, i've made it into %INCLUDE{"!%MAINWEB.WebLeftBar"}% , where MAINWEB = Hsa

  • So I understand you would go for option 2? But then you don't have web specific links in the left bar? -- ArthurClemens - 08 Aug 2004

-- SvenDowideit - 08 Aug 2004

Why not have a %WEBLEFTBARTOPIC% variable. Then you can set it on a site/web/user basis. Out the box it should have a site wide left bar but it would leave admins free to configure it however they want without having to change the template. The biggest benefit of this approach is that you could then have some webs inheriting the site setting and some having custom left bars. This could equally apply to headers/footers.

  • Thinking about how the webs are used I think people will almost always want a web-dependent leftbar. If not, you can do an %INCLUDE{%TWIKIWEB%.WebLeftBar}% in the web's leftbar. -- ArthurClemens - 09 Aug 2004

However this may get confusing when viewing other users home pages (or other topics that set it). It's a pity that you can't specify user settings like this (or the TOPICSTYLE settings) in a way that doesn't affect other users when they view your home topic. Perhaps it should be final in the web settings.

If you do go with a solution that has a WebLeftBar topic in every web but by default including one from the TWiki Web then it might be best to have one in the _default web.

%INCLUDE{TWiki.WebLeftBar}%

-- SamHasler - 08 Aug 2004

Arthur, how about adding some CSS for a nice horizontal rule (<hr>), please?

-- WillNorris - 10 Aug 2004

I am creating a zip file for this skin. Should I include these TWiki and Main topics too? I was thinking yes.

-- ArthurClemens - 10 Aug 2004

definitely yes. part of the skin functionality is now embedded in topics (which i think is a good thing ;))

-- WillNorris - 10 Aug 2004

This is a hr


This is text following the hr

-- ArthurClemens - 10 Aug 2004

Like the color?

BTW, PatternSkin is now zipped. Its final!

-- ArthurClemens - 11 Aug 2004

Yay PatternSkin! Kudos and thanks for all your hard work on this Arthur -- especially the usability improvements.

I think -Cancel- (on Edit screen) should look like a button. At the moment it doesn't even look like a link, let alone a functioning command.

-- MattWilkie - 11 Aug 2004

Why should Cancel on the Edit page look different than on other pages?

  • Not that I really care, but why do any of the options, "Save", "Checkpoint", "Upload" (for attachments), etc. look like buttons, but Cancel doesn't? -- BruceDillahunty - 11 Aug 2004

  • I want to give focus to the forward flow of edit - ( preview - ) save. Cancel is a deviation from the normal flow. But I agree it can be a bit more link-like, like the links in the view page. -- ArthurClemens - 11 Aug 2004

  • I have added an underline to the Cancel link. This brings it more in line with the view page action links. Clear your cache before viewing an edit screen - my cache is very sticky... -- ArthurClemens - 11 Aug 2004

-- ArthurClemens - 11 Aug 2004

Ohoh, that's no good. I used the GoBox and was forced to login before it would execute.

-- MattWilkie - 12 Aug 2004

Speaking of page borders, I remember there being a rather large border on the edit page. I tried checking now but I can't find the user/password for the links above to test the edit page. I know I could write my own user css and get pattern to use that but I think having a wide edit textarea is something a lot of users will want out the box.

-- SamHasler - 12 Aug 2004

About Edit screen margins:

  • You do need a margin to frame the page. Again, it is related to the monitor screen width. But I am willing to play a bit more with the margin width. Not too much, because the margins on the Edit and Preview pages are the same as on the More page and other twikiNoView pages.

Addition: I think it would be useful to show if a topic is locked and the lock duration.

  • This is a great idea. Making the locking system more "visible" wouldn't hurt a bit. It's technical stuff, but it's definitely part of what makes TWiki work. -- SteffenPoulsen - 13 Aug 2004

-- ArthurClemens - 13 Aug 2004

Search results seem to be knackered on twiki.org. See Support?skin=pattern

  • Looks like there is a closing div where it shouldn't. And a table without an opening table tag. Can't reproduce it on the test site, probably in some included result. Will look into it further, later. -- ArthurClemens - 14 Aug 2004

-- CrawfordCurrie - 14 Aug 2004

Today's CSS update:

  • Made the twikiNoViewPage screens wider
  • Made the Edit screen even wider
  • Made the left bar smaller
  • Used most of Steffen's changes for the print page - With me works fine now, but please test again.
  • Colorized code and pre contents. Makes pages more readably to my opinion.
    • Haha, the old geeks here won't have their verbatim in anything else but 100% typewrited black - but I kinda like it. -- SteffenPoulsen - 14 Aug 2004
  • Fixed a table formatting bug on Explorer Win on the print template (SVN, not yet on twiki.org)
  • Fixed padding and margin on normal tables in topics (there was no padding and margin)

I found Mozilla on Windows (1.7.2) has a problem to render the arrow icon for the TOC. The image url is right, if you enter that in your browser you will see the arrow image, then go back, the TOC will show the icons. Reload and they vanish. I'm puzzled. Could it be a problem that the image url is added in the html after the css @import?

  • Firefox (0.9.2 Win) has somewhat similar - the first page you view after you start Firefox, won't show the TOC icon. The next ones will. Guess it's some kind of internal cache- / render-bug or similar in the mozilla engine. -- SteffenPoulsen - 14 Aug 2004

-- ArthurClemens - 14 Aug 2004

More updates:

  • Fixed a new introduced layout 'bug' in edit template webform
  • Moved help text in attach template below topicaction buttons so I don't have to scroll always; layout will look queer on twiki.org until template update
  • Forgot to mention that I have reintroduced plain text links (not bold) in leftbar and TOC
  • Now the twikiNoViewPage and twikiEditPage really differ

-- ArthurClemens - 14 Aug 2004

Regarding the rendering errors in Support.AskedQuestions / Support.WebHome / other topics that uses searches with noheader on, I tried to track the problem a bit further.

There's an issue in search.pattern.tmpl when noheader is set to on. The searchbody template looks like this:

%TMPL:DEF{"searchbody"}%%SPLIT%<div class="twikiSearchResults">
<div class="twikiSearchResultsHeader" style="background-color:%WEBBGCOLOR%">
Results from %WEB% web</div><table width="100%" border="0" cellspacing="0" cellpadding="0">
%TMPL:P{"repeatedsearchblock"}%</table></div>%SPLIT%
<div class="twikiSearchResultCount">Number of topics: <b>%NTOPICS%</b></div>%TMPL:END%

But when noheader is on, the part in front of the repeatedsearchblock is more or less left out, leaving only the right part, and in particular the closing tags for the table and the div (it's related to lines 991 and following in Search.pm). The solution could be to break up the header and the results into two different tables, instead of keeping them in the same (so that the header and result sections can be "mutually exclusive", the latter not requiring the former).

I put a testpage demonstrating the problem at the testsite (dekko.nl). You can try the page out at the w3c validator - it complains about the table and div tags as well.

-- SteffenPoulsen - 15 Aug 2004

I see now that the problem is in search.pattern.tmpl, because of my former poor understanding of what happens with the REPEAT tags. Unfortunately it is not so easy to repair, because search is used in changes.pattern.tmpl, searchrenameview.pattern.tmpl, rdiff.pattern.tmpl, searchbookview.pattern.tmpl, searchformat.pattern.tmpl. I will need to dispense with the table formatting and to replace it with a div approach.

-- ArthurClemens - 16 Aug 2004

FIXED!

I have changed tables to divs, shuffled a bit, and now all seems right.

Verification table of search dependent templates/pages: (tested on Win IE 6, Win IE 5.5, Win Mozilla 1.7, Mac Safari 1.2.3)

Final test pages here on twiki.org (when the new templates are updated): ContribPackage and Support.AskedQuestions

-- ArthurClemens - 16 Aug 2004

I have updated CVS and PatternSkin.zip

-- ArthurClemens - 17 Aug 2004

It looks like the search is working perfectly here now, too - impressive fix-swiftness smile

I cross my fingers that this will be the default skin for the Cairo release (even though I realize the performance issues).

-- SteffenPoulsen - 19 Aug 2004

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2006-02-03 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.