Avatar

Journal of the growth of a mobile aware template (Design/Themes)

by Auge ⌂, Wednesday, June 29, 2016, 11:07 (2829 days ago)

Hello

Let's start.

I want make a resposive template for My Little Forum 2. As the base of my attempt I use the default template. This template was made years before viewing website with smartphones was common. thatswhy it is not prepared for that nowadays common usecase.

As a first step I fiddled around with the main template, especially the main view of the threads (in threaded view) with it's sidebar boxes. As a first result the main elements are linearised. That looks ugly in a desktop browser but a bit more satisfying in a narrow viewport (here: Firefox developer tools).

Main page in a desktop browser:

[image]

Main page in a "mobile" view (Firefox developer tools):

[image]

This is only a interim state, not the final solution!

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Journal of the growth of a mobile aware template

by needhelp2, Thursday, June 30, 2016, 05:20 (2829 days ago) @ Auge

THANK YOU so much for doing that.

Is it possible to minimize or collapse the Sidebar? Maybe that will make the design cleaner and easier to navigate?

Avatar

Journal of the growth of a mobile aware template

by Auge ⌂, Thursday, June 30, 2016, 12:56 (2828 days ago) @ needhelp2

Hello

THANK YOU so much for doing that.

Is it possible to minimize or collapse the Sidebar?

Not yet, but later it will.

Maybe that will make the design cleaner and easier to navigate?

Yes, at the moment I will concetrate on the code cleanup. The current status is far away from production readyness, so this is of no importance at the moment. Later in the process, the focus will change and it will be important and it will be changed.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Journal of the growth of a mobile aware template

by Auge ⌂, Friday, July 22, 2016, 15:58 (2806 days ago) @ needhelp2

Hello

Is it possible to minimize or collapse the Sidebar? Maybe that will make the design cleaner and easier to navigate?

Sorry, I misunderstood you. Yes, you are able to minimise the sidebar. You can do that anyway with the default template. The word "Sidebar" in the main header bar is a link and the small minus (-) or plus sign (+) in the top right corner of the bar is also a link. With both links you can collapse and expand the sidebar.

I changed this behaviour a bit in my template. The link with the minus or plus sign has gone. Instead of that the complete title bar of the sidebar, where you see the mouse pointer, is clickable to collapse and expand the sidebar. I don't know, if the script allows to change the standard behaviour at some points with JavaScript via the template. If yes, I would make the collapsed sidebar the standard behaviour in case of very narrow viewpoints (moible browsers).

[image]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Journal of the growth of a mobile aware template

by Auge ⌂, Friday, July 01, 2016, 15:25 (2827 days ago) @ Auge

Hello

As second I tried to change the main "table view". For the "mobile" view (Firefox developer tools) I rearranged the table rows and fields, hid the headers, put their text values into attributes I named "data-header" and blend it in via CSS (td[data-header]::before { content: attr(data-header) ': '; }).

[image]

For comparision purposes the main view threaded, mobile again.

[image]

As last an impression, a screenshot from my phone in it's original dimensions.

[image]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Discussion about the need of title-attributes

by Auge ⌂, Wednesday, July 13, 2016, 11:04 (2815 days ago) @ Auge

Hello

During the work on the template I found a veritable bunch of title attributes. I'm sure, I'll find further ones in the future ;-).

In my humble opinion these attributes are obsolete.

In ancient times a simple way to avoid displaying the value of the images alt-attribute was to integrate an empty title-attribute. Over the time the forum script got more and more title-attributes (with nonempty values) for more and more elements.

  • Many of them has identical or at least similar values with only small changes to i.e. elements link textes or alt-attributes. The informations, wich additionally are delivered with title-attributes, are redundant in many cases.
  • If an information is important for the user, it should not be the value of a title-attribute. It should be the readable content of any HTML-element instead.
  • All of them are not accessible on touch devices.
  • All of them inflates the size of the forums source code in it self and of the transfered data in case of requests for the generated web pages.

In my own theme I can disable the titles by removing them from the Smarty-templates. But the code in the script to enlive the attributes with their values and the values in the language files will and must stay for the use in different themes. Any thoughts about removing the code itself?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Discussion about the need of title-attributes

by Micha ⌂, Wednesday, July 13, 2016, 17:25 (2815 days ago) @ Auge

Hi Auge,

  • If an information is important for the user, it should not be the value of a title-attribute. It should be the readable content of any HTML-element instead.

The title contains the non-important information e.g. additional information.

Any thoughts about removing the code itself?

The title-attribute is not the reason for its bad content/wrong use.


/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Discussion about the need of title-attributes

by Auge ⌂, Thursday, July 14, 2016, 09:14 (2815 days ago) @ Micha

Hello Milo

  • If an information is important for the user, it should not be the value of a title-attribute. It should be the readable content of any HTML-element instead.


The title contains the non-important information e.g. additional information.

Yes, but it's not seldom (in mlf2), that these informations are a new formulation of an existing text (content or value of a different attribute). In these cases the informations are redundant and IMHO unnecessary. The last I would also assume in cases of non-important informations.

Any thoughts about removing the code itself?

The title-attribute is not the reason for its bad content/wrong use.

That's correct. :-)

I don't want to ban title-attributes at all. I want discuss the need of such an amount of title-attributes, notably under the assumption that users of touch devices can not access the title-attributes values. If we want to make the software accessible for these users, we should discuss, wich informations are important (and should be presented in a different way) and wich not (can be removed or stay as the attributes value).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Discussion about the need of title-attributes

by Micha ⌂, Sunday, July 17, 2016, 08:09 (2812 days ago) @ Auge

Hi,

notably under the assumption that users of touch devices can not access the title-attributes values.

But other devices are able to show the attribute. So, I don't see the benefit of removing an attribute that works fine on common devices. The new template should be valid for all devices, shouldn't it?

If we want to make the software accessible for these users

... we should't restrict the software for other users. The users knows the limitation of a small device, he/she don't expect a full compatibility.

I believe, it is easier to keep the title-attribute, than to add it retroactively to the source code.

Have a nice weekend
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Discussion about the need of title-attributes

by Alfie ⌂, Vienna, Austria, Monday, July 18, 2016, 09:46 (2810 days ago) @ Micha

Hi,

But other devices are able to show the attribute. So, I don't see the benefit of removing an attribute that works fine on common devices. The new template should be valid for all devices, shouldn't it?

If we want to make the software accessible for these users

... we should't restrict the software for other users. The users knows the limitation of a small device, he/she don't expect a full compatibility.
I believe, it is easier to keep the title-attribute, than to add it retroactively to the source code.

I agree. It is difficult to predict how a forum is accessed from server-logs. For some installations access from touch-devices (smartphones, tablets) is substantial, for others it is negligble. F.i. my forum is accessed only ~5% from mobile devices (guesstimate based on the OS and browser).

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

Avatar

Discussion about the need of title-attributes

by Auge ⌂, Monday, July 18, 2016, 13:40 (2810 days ago) @ Alfie

Hello

I believe, it is easier to keep the title-attribute, than to add it retroactively to the source code.


I agree. It is difficult to predict how a forum is accessed from server-logs. For some installations access from touch-devices (smartphones, tablets) is substantial, for others it is negligble.

ACK

F.i. my forum is accessed only ~5% from mobile devices (guesstimate based on the OS and browser).

Sorry, but mlf1 is not appropriate to set a standard in accessibility. The HTML- and CSS-code-structure of mlf1 is not qualified to be accessed with mobile devices. It's a chicken-and-egg question if you haven't mobile users because they don't want to use mobile devices or because they have such devices but can't read the forum with it. :-(

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Discussion about the need of title-attributes

by Auge ⌂, Monday, July 18, 2016, 13:27 (2810 days ago) @ Micha

Hello

It seems to me, that we are at cross-purposes.

notably under the assumption that users of touch devices can not access the title-attributes values.


But other devices are able to show the attribute. So, I don't see the benefit of removing an attribute that works fine on common devices. The new template should be valid for all devices, shouldn't it?

Once again: It's not about title-attributes are bad and should therefore be removed. But if the value should be known to every user (independent from the used device) the title-attribute is the wrong place to store this piece of information.

If we want to make the software accessible for these users


... we should't restrict the software for other users. The users knows the limitation of a small device, he/she don't expect a full compatibility.

It's a limitation, to set an important information as normal text instead as attribute value? Sorry, wrong way around.

If an information is important, it should not be the value of an attribute, that is inaccessible for some of the users. That's a bug in design. If it is only a redundant information, it's IMHO unnecessary. In all other cases – neither a need-to-know nor a already-read-aside – it's ok, to deliver an additional information in a title-attribute, because it's not bad not to read it.

I think that many of the title-attributes in mlf2 are ok. But in some cases the use of the attribute is either inappropriate or unnecessary. IMHO we should identify these cases and remove the affected attributes.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Form elements, version 0.0.4

by Auge ⌂, Friday, July 22, 2016, 21:26 (2806 days ago) @ Auge
edited by Auge, Monday, February 27, 2017, 14:20

Hello

Restricting the width of inputs is a bit tricky. Most of them has the attribute "size", which restricts the width by the number of chars in the field. In narrow viewports this leads to inputs that rises out of the layout and the viewport. Restricting the width with the simple rule input { width: calc(100% - 6px); } catches also inputs of the type radio and checkbox. So these elements took the rule serious and in consequence the whole width. :-(

So I tried to exclude these types with the selector :not(), but it doesn't take lists of selectors (i.e. input:not([type="checkbox"], [type="radio"])). Thatswhy I needed another solution and found a not very elegant but robust way with a dedicated class, that I named "small-input" (input:not(.small-input) { width: calc(100% - 6px); }).

I gave it to every checkbox, every radio-button and – after a first scary test – to a few text inputs in the settings section. I had to work on the submit buttons also, because they used the full width too. I changed them all from <input type="submit" /> to <button></button>.

An exemplary view from the settings form. I know, it's not very thrilling. :-)

[image]

I tend to use HTML5-types for the element input and the new attributes, where it's possible. So the search inputs are now of type="search" and has placeholders via attribute instead via JavaScript.

The packages are available in my repository on github.com. Actually the version 0.0.4 is the newest one.

Disclaimer: At the moment the template named "response-one" is not suitable for productive use. Use it only for testing purposes from your personal settings after the upload!

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Form elements, version 0.0.4

by Micha ⌂, Monday, July 25, 2016, 19:00 (2803 days ago) @ Auge

Hi,

I changed them all from <input type="submit" /> to <button></button>.

The current version of mlf doesn't use the new element <button> because of some problems with (former) IEs, e.g. Button tag in bloody Internet Explorer.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Form elements, version 0.0.4

by Auge ⌂, Tuesday, July 26, 2016, 18:53 (2802 days ago) @ Micha

Hello

I changed them all from <input type="submit" /> to <button></button>.


The current version of mlf doesn't use the new element <button> because of some problems with (former) IEs, e.g. Button tag in bloody Internet Explorer.

Former Versions? Ancient versions, because IE supports <button> to submit a form since IE7 (link to SelfHTML (german language)). :-)

That's not a problem, because it's a part of a theme for modern browsers. If anyone uses an ancient IE (< 7) he doesn't need a theme for modern browsers and – as you said – the default theme supports these ancient browsers.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

The views for the entries and some questions @Milo

by Auge ⌂, Tuesday, August 02, 2016, 11:39 (2795 days ago) @ Auge
edited by Auge, Tuesday, August 02, 2016, 14:38

Hello

I fought with the threaded and linear views of a thread. Some things I rebuilt:

- The openig entry is hierarchically an equivalent of it's answers. Before it was the parent-element (header-wise).
- Some of the informations about the author and the posting itself will be faded out for the mobile view.
- The taglist and the count of the views are now part of the meta information block (a.k.a. <header>).
- The link to the answer form is now part of the option list below the entry. For most users it's the only option.
- Every entry is an <article>.
- The elements for title, author info and the tag list (if available) are content of a <header>.
- the footer is now, what it claims to be, namely a <footer>.

A thread in a narrow viewport (Firefox developer tools). The image is shrinked by a quarter of it's original size (width and height). The first entry is closed with a click on it's title, only the header is displayed.

[image]

You see, there are some minor problems.

As first, the information bar about the author and entry contains some orphaned commas. The reason is the outfade of the website- and e-mail-link, the posting time (with date and time) and the IP (for admins). The commas are part of the strings in the language files. I can't skip them without skipping the whole block and display the authors name and entry date again. This would be cumbersome and not very robust. A possible solution would be the disintegration of the language string into different parts, wich can be displayed part by part in own HTML-elements.

But that needs changes to the source code of the forum script.

A second problem ist the way how entries are skipped by clicking/tapping it's title. At the moment some of the HTML-elements get an inline-style-attribute via JavaScript (resulting in <element style="display: none;">). I would like to set a class-attribute to the whole container of the entry (the <article>-element in my template) and use style-definitions in the CSS-file instead. The main reason is the flexibility and portability of this system.

My template could contain the following CSS-definitions (given class name: "posting-faded-out"):

.posting-faded-out .avatar {
    width: 2em;
    height: 2em;
}
 
.posting-faded-out .tags,
.posting-faded-out body,
.posting-faded-out footer {
    display: none;
}

another one could set different rules, i.e.:

.posting-faded-out .avatar,
.posting-faded-out .tags,
.posting-faded-out body,
.posting-faded-out footer {
    display: none;
}

Further informations at a later time.

Edit:

@Milo: What is the effort to change the JavaScript at this point? Are there further places with similar behaviours?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

JavaScript questions @Milo

by Micha ⌂, Sunday, August 14, 2016, 11:32 (2783 days ago) @ Auge

Hi,

@Milo: What is the effort to change the JavaScript at this point?

I don't know. ;-) At the moment, it seems to be a small effort. I believe, we have to change some lines in main.js.

Are there further places with similar behaviours?

I suppose so.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

JavaScript questions @Milo and @Alex

by Auge ⌂, Monday, August 15, 2016, 12:03 (2782 days ago) @ Micha

Hello

@Milo: What is the effort to change the JavaScript at this point?

I don't know. ;-) At the moment, it seems to be a small effort. I believe, we have to change some lines in main.js.

This seems to be the right place.

<div class="thread-posting new" id="p9130">
<!-- header, body and footer of the entry -->
</div>

We only need to set or remove a class name, set appropriate CSS-rules for the default template and remove the JS-setted foo.style.display orders. Is there something that I forgot?

Are there further places with similar behaviours?

I suppose so.

I saw the all spinner graphics beside the submit buttons, where visibility:hidden; will be toggled. But I didn't found the corresponding JS-code.

Are you aware of additional places?

And one more question:
Is it possible to add theme-dependent JS-code without interaction with the main.js?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

JavaScript questions @Milo and @Alex

by Micha ⌂, Tuesday, August 16, 2016, 10:32 (2781 days ago) @ Auge

Hi,

We only need to set or remove a class name, set appropriate CSS-rules for the default template and remove the JS-setted foo.style.display orders.

Yes that's right.

Are there further places with similar behaviours?

I suppose so.


I saw the all spinner graphics beside the submit buttons, where visibility:hidden; will be toggled. But I didn't found the corresponding JS-code.

I belive, it is located at posting.js

Are you aware of additional places?

No, I'm sorry. We have to check every modification.

Is it possible to add theme-dependent JS-code without interaction with the main.js?

You can add another JavaScript file. To avoid conflicts, choose unique class-names.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

JavaScript questions @Milo and @Alex

by Auge ⌂, Tuesday, August 16, 2016, 10:57 (2781 days ago) @ Micha
edited by Auge, Friday, August 19, 2016, 13:25

Hello

I saw the all spinner graphics beside the submit buttons, … But I didn't found the corresponding JS-code.

I belive, it is located at posting.js

Aha!

Are you aware of additional places?

No, I'm sorry. We have to check every modification.

I found another one. The (not-) displaying of the side- and the bottombar is had the same behaviour (foo.style.display = …;).

[edit]
I'm collecting find spots:

  • generating and displaying the elements #bbcode-options, #ajax-preview and #image-canvas (I don't know the purpose of the latter two elements)

[/edit]

Is it possible to add theme-dependent JS-code without interaction with the main.js?

You can add another JavaScript file. To avoid conflicts, choose unique class-names.

Ah, „manual“ namespaces.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

JavaScript questions @Milo and @Alex

by Micha ⌂, Saturday, August 27, 2016, 08:14 (2771 days ago) @ Auge

Hi,

generating and displaying the elements #bbcode-options, #ajax-preview and #image-canvas (I don't know the purpose of the latter two elements)

The first (#ajax-preview) is used to show the posting by clicking at the [image]-icon. The second one (#image-canvas) is used, when you enlarge an image, eg.g [img=thumbnail].

Is it possible to add theme-dependent JS-code without interaction with the main.js?

You can add another JavaScript file. To avoid conflicts, choose unique class-names.

Ah, „manual“ namespaces.

No, that's not the right description. I believe, the JavaScript is robust and you can add your own code. Just avoid object names that are still in use like Posting (e.g. new Posting(<id>).

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

The views for the entries reworked

by Auge ⌂, Monday, February 27, 2017, 14:43 (2586 days ago) @ Auge

Hello

After the inclusion of the changes, that came in with version 2.4, I reworked the nested view of a thread. Here, for comparision, the screenshot of the old state.

[image]

The problem with the way, how the visibility of the elements were toggled, and with the orphaned commas was solved with the mlf version 2.4. So here is the screenshot of the actual state.

[image]

Because of the changed way of toggling, one can hide elements, can resize elements (like I did it with the avatar image) or anything else, what's possible with CSS. The commas are also hidden. Tzhe parts of the authors info are selectable one by one by speaking class names and the commas via the class .interpunction.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Presentation of the entries, version 0.0.5

by Auge ⌂, Friday, August 12, 2016, 19:56 (2785 days ago) @ Auge

Hello

As shown before, the actual step affected the views of the entries. I overhauled the linear-, threaded- and the one-entry-per-page-views and unified the HTML-structure as far as possible. Every single entry has it's own article element, independent from the selected view. Only a few classnames are view-dependent to distinguish one view from the other for the styling purposes.

<article>
 <header><!-- title, authors info, new: number of views, tags --></header>
 <div class="body"><!-- the entry itself --></div>
 <footer><!-- the list with the actions (ul.options), the answer-link is now a member of that list --></footer>
</article>

Below you see the screenshot, that I showed already in the above linked entry.

[image]

Meanwhile the quotes has – with exception of the font size – it's old styling (grey colour, intendation, qoutation-marks image) back. I say that, because the sentence "Dies ist ein weiterer Testeintrag, …" in the screenshot is a quote from the folded entry above. The in the linked entry described problems are still present.

I can't solve these problems without code changes what leads to a new program version. Thats a task for the team, not only for me.

You can always load the new development release from the repository. Load it into the directory "themes" beside the default theme and activate it for testing purposes as your personal theme.

Tschö, Auge

PS (and btw): The code-highlighter-plugin, that the script uses, is not HTML5-aware.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

admin interface, v0.0.7

by Auge ⌂, Monday, February 27, 2017, 16:11 (2586 days ago) @ Auge

Hello

After a half year of silence in this thread, I can proclaim: I work on the theme again.

With the version 2.4 of MLF some small changes were introduced, which makes it easier to manipulate the pages content in some corner cases. The version 0.0.6 of the theme was the integrations of most of the theme related changes of MLF 2.4. With the version 0.0.7 of the theme a few forgotten improvements of MLF 2.4, the new elements in the admin menu and the bookmarks list was in focus of the changes.

[image]

I presented especially the improvement of the nested and linear views of a thread in another entry. Here is, what I'm working on now (including a few questions).

I struggle with the menus. There are two relevant menus.

The first is the one with the id #usermenu, where on can log in, log out, change the user settings and, if one is an admin, can reach the admin menu. The menu is located in the page header, as a list in one line. Then there is the #submenu with one or two separate menus (left and right). These two menus are also one liners in the default template but I made them vertical lists, as you can see in the screenshots of this entry.

Now I give a different structure a try. I put all two or three menus into one parent element. Now all menus are vertical lists, wich are separated by a bottom border as you can see in the first screenshot.

You see the menu, that takes most of the height of the screen of my phone. It should be easy to distinguish between the lists. There are two tasks.

  • Hide the menu and show it with a slide-in or a special menu button which is not existing nowadays.
  • Get an idea about the layout on a wide viewport. Format the menus as horizontal lists one by one is not a problem. But how to display them one beside/below the other(s)?

Can anyone describe a possible solution?

[image]

A second question is the breadcrumb navigation (if present: left menu of #subnav). I left the left padding of 14px for the links from the default theme (the images itself are not included in the moment). The breadcrumb trail has no left padding. Maybe existing links in the breadcrumb trail have this padding. At that point I saw that the breadcrumb is handled inconsequent. Some pages have one, other pages not. In some pages I found a link to the main page, on others only to the parent page (i.e. in the admin menu).

Especially but not exclusively to @Milo: Is it reasonable to unify the behaviour on the different pages/sections?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread