Tsunami [theme]

[Bloc]

Tsunami is a modern theme inspired by some recent projects I was working on, utilizing the idea of harnessing CSS grid for the many tabular or table-like templates in SMF(or SMF forks). My primary goal has been to create a working boilerplate for future themes. Its responsive (not only towards mobile devices, but also to a lesser degree wide-screens) and have many images replaced by typefonts or svg's.

Featurewise its not that much different than default...though for forum administrators there is a box in "current theme settings" where you can add your own modified styles. They will then carry over when the theme is updated.
Below is the status of current versions,  also shown inside current theme settings in the theme, giving you a visual update of the development.

Demo: https://bhksite.info
Github: https://github.com/blocthemes

Current versions

     

Further plans include:
- more common subtemplates
- same theme developed for SMF 2.1, ElkArte and possibly Wedge
- more custom user options
- removing more images in favor of svg/typefont
- color variations

Will post updates in this topic as they emerge.

[Bigguy]

Screenshots are very nice. Good work. I don't see a demo at the link though.

[d3vcho]

You should click the "SMF 2.0 FORUMS" link to see it.

[Biology Forums]

Will install tonight! Writing for reference only.

Thanks Bloc

[Bloc]

Spotted one mistake on my part: seems the version image inside the theme is a bit outdated Will be fixed in next minor version though.

...which beckons th question of having some sort of auto-updating of the theme...but afaik this isn't possible within SMF. You know, the way for example Wordpress updates their themes.

TIP: Anyone with a bit knowledge could use Git and pull straight from the github repo. Thats how I have the demo-site at bhksite.info setup. Does require access to the webserver of course but combined with adding your own changes in the CSS within the theme itself, you'll have a nice semi-automated updating system.

[Antechinus]

Looks interesting. I'll load it on local later.

[Bigguy]

You should click the "SMF 2.0 FORUMS" link to see it.

I see it now, very nice.

[Antechinus]

Well that's an interesting result. Installed the 2.0.x version on local. No CSS. Outputs straight HTML only.

ETA: Hmmm. Ok, initial problem was that the zip download from github (may its name be cursed forever) extracts with an extra folder, so the files are one level too far down to be functional as extracted.

So, shift said files one level up. Cool. Now it says "Unable to load the 'main_above' template.".

Will keep digging...

ETA again: Also, the theme_info.xml file has no content. Completely empty. Zero bytes of info. Then I notice that all PHP files are also zero bytes. No content. Empty. No wonder it doesn't work.

Something is badly wrong with the github download.

[Bloc]

Try using 7-zip. I can download it just fine and all files opens up as they should.

True, Github zipping does create a extra folder so you can't just use the downloaded zip and upload it, rather you must extract it and either upload as pure files/folder into Themes...or zip it up again one level less. But there so many benefits with using Github that I expect those who wants to use the theme, also can handle this.

[Antechinus]

Ah. Works now. Looks like going via 7zip is essential. Might pay to make a note of it.

(IOW, unzipping via SMF admin creates a stack of files with all zero byte counts, while unzipping via 7zip doesn't screw them).

[Biology Forums]

Not sure about everyone else, but these SVG blocks look incredible:



You always learn something new, I had no idea you could do that

[Antechinus]

Well they look like rectangles with text in them, which is not particularly incredible in itself. I'll agree they're a nifty bit of coding though.

[Bloc]

Ah. Works now. Looks like going via 7zip is essential. Might pay to make a note of it.

(IOW, unzipping via SMF admin creates a stack of files with all zero byte counts, while unzipping via 7zip doesn't screw them).

Strange. I wonder if that happens on SMF2.1..will check when I start on it.

Not sure about everyone else, but these SVG blocks look incredible:



You always learn something new, I had no idea you could do that

Yep. Out of necessity, because I needed some way of updating the showing of version number dynamically and whats better than a small text-based svg? Kind of surprised it worked myself actually hehe. Then again, using svg - and aslo actually writing them by hand - is a valueable learning exercise, at least for simpler things. It can include images too, but I found it hard to actually work inside a IMG tag(or in SMF a [ img ]). In HTML it works fine.

[gecitli]

very nice, especially your coding style is great.

[muffinabyss]

Looks really good on my iPhone SE (2.0 demo on your site). Probably the best theme I've seen for 2.1 so far too

[-Rock Lee-]

Oh pretty good indeed, great job @Bloc!


Regards!

[Antechinus]

I've had a bit of a play with the 2.0 version. I like the overall look and feel. Not really keen on the home page's large screen layout though (easy to customise anyway). Feels a bit chopped up to me. Sorts itself nicely on narrower screens though. Main menu handling is excellent on narrow screens. Not so keen on the drop styling on a large window (content tends to feel a bit lost, IMO). Also not keen on the current admin/profile/etc drops. Those are just awkward at the moment, IMHO.

Having the top level links switch to a footer bar when the screen narrows is an interesting idea, once you get your head around where they have suddenly vanished to, but I'm not sure if it's just clever or actually good. It's inconsistent with the submenus (meaning #adm_submenus items) but OTOH having it available all the time should be handy. The mixture of click for top level and hover for second and third levels doesn't feel right to me though. I'd be inclined to make it consistent all the way down (but then you know my feeling on click vs hover as we have been here before).

Oh, and IMO the quickbuttons still being in the (really dumb) 2.0 location should be changed to the (IMO much better) 2.1 location below the post content. It's better in terms of usability, and you're upending the whole thing anyway, so might as well make the UI consistent across both versions.

(And please kill all instances of that horrible ie6_header abomination I was forced to use at the time in 2.0.x templating. That was a sin for which I will never be forgiven.)

[Antechinus]

Hey question: in index.template.php you're using if($mobil) to switch menus, but it doesn't appear to be defined anywhere. How does that work?

[Biology Forums]

Of topic, I too use an is_mobile variable throughout my responsive theme, although I try to minimize it as much as possible. Is that how the big players do it too when making a responsive theme?

[Antechinus]

It's one way of doing it. What has me stumped at the moment is that he has the variable mentioned in two places in index.template.php:

Code Select Expand

// Show the menu up top. Something like [home] [help] [profile] [logout]...
function template_menu($mobil = false)
{
global $context, $settings, $options, $scripturl, $txt;

if($mobil)

But, it's not mentioned anywhere else, so I can't see how it is defined so that it can be usable.

[Diego Andrés]

It's one way of doing it. What has me stumped at the moment is that he has the variable mentioned in two places in index.template.php:

Code Select Expand

// Show the menu up top. Something like [home] [help] [profile] [logout]...
function template_menu($mobil = false)
{
global $context, $settings, $options, $scripturl, $txt;

if($mobil)

But, it's not mentioned anywhere else, so I can't see how it is defined so that it can be usable.

Code Select Expand

<nav id="mobilnav">
<input type="checkbox" id="mobilmeny" />
<label id="mobilmeny_label" for="mobilmeny" onclick><span class="icon-menu"></span></label>
' , template_menu(true) , '
</nav>

Of topic, I too use an is_mobile variable throughout my responsive theme, although I try to minimize it as much as possible. Is that how the big players do it too when making a responsive theme?

Depends on what you want to do with the menu really as it could be just css, realistically those are the only 2 options I can think of doing it

[Bloc]

Diego spotted it. Its just a switch to render slightly different HTML for the mobile menu. The CSS does the work.

Antechius, *nodding* - I am going through errors and glitches now and tend to agree on the menu thing..at least for the admin menu it tends be awkward. I think I will go for the sidebar option + perhaps slidedown for submenus(on click) for the best mobile experience too. Having the menu at bottom for mobile is interesting but once its get too many items the real estate is too narrow there. Plus the non-solution of submenus as hovers..which I actually forgot lol.

quickbuttons under the post? Makes sense, I'll try that.

Wide layout option for large displays..kinda like using all available space, BUT I see now that the member-sidebar doesn't really do much other than ..member stuff. I might work that up to the top instead and go for just 2 column-layout instead of 3-columns.

..on another note, read an interesting article about the new toolset of flex/grid can actually makes media queries obsolete, by thinking "objects" instead of endlessly finding best possible scenario for any given layout. It requires all "objects" to care for themselves, that is , adapt to any given width and have a min-width. Objects then shift around depending on overall width. Sort of like "cards" in Pinterest but of course with more finesse.  This will not go into this theme but I might pursue it in another. 

[Antechinus]

Yes the large window presentation is going to be a personal preference thing. I tend to like things centred and balanced laterally. Some people don't. That's fine. As they say in the classics: if you want the bloody thing different, code it yourself.

Re the toggle variable: I get that you're using the checkbox trick to switch the menu markup. What stumps me is that your php variable is $mobil, but that's not mentioned in the code Diego quoted.

Code Select Expand

<nav id="mobilnav">
<input type="checkbox" id="mobilmeny" />
<label id="mobilmeny_label" for="mobilmeny" onclick><span class="icon-menu"></span></label>
' , template_menu(true) , '
</nav>

It says all sorts of stuff there, but it doesn't say $mobil. I thought PHP variables had to be defined with special voodoo like $context and $modSettings. Mind you I don't know much PHP. Are you saying that if I wrote markup like:

Code Select Expand

<fieldset id="my_old_mans_a_dustman"> etc

I could just throw in $my somewhere else and it would automatically do stuff?

[Bloc]

A PHP function can have a parameter that you supply in the call...but if you then call it without the parameter, it errors out. One solution is to define the parameter within the call..so I set $mobil to be defaulted as "false". Meaning when I call template_menu() without the parameter ($mobil exists only within the function) $mobil get set to "false". But if I call template_menu(true) that same local $mobil is set to TRUE. Simple.

[Antechinus]

Aha. Sneaky. I like it.

[Bloc]

What have become painfully obvoius working with the mobile version of Tsunami is how much buttons/clutter/menus there really are in a theme..for now I'll sort out just the main obstacles, but in the longer run - perhaps another theme project - I like to hide all those choices, using all I can of fly-outs and clickmenus instead. Becuase there is one thing a mobile have no problem with(and what people are used to be doing)  - and that is to click on things.

[Antechinus]

Lol. Did you ever see the 1.1.x mobile theme I made yonks ago? That had click flyouts for Tiny Portal sidebars, and for memberlist sorting options, and for all the huge smiley collection that site had. Kept the kids amused.

(Yes, they did want all that stuff)

[Biology Forums]

Actually that's what started it all for me. It was the first mobile theme I had ever made for my site, and I built it off the bones of your original mobile theme. I remember emailing you back in 2015 for the files -- what an interesting time

[Bloc]

- New version 1.1 with various tweaks and updates. Menus in admin/profile/moderation etc. have been transformed to sidebar with collapsable sub-items and they both open a slideout-by-hamburger-icon when in smaller resolutions.

Also new page for links,demo and downloadable zip, since Github does its zips with an extra folder: http://www.bhksite.info

[Antechinus]

Sounds nifty. Will have a look.

Hey I need to register to download. Is this a new site, or do I still have an old account there?

ETA: Nevermind. Grabbed it from ButtPlug and rezipped it myself. Now that I know what tricks it's up to, the workaround is a piece of cake.

[Antechinus]

First impression: looks pretty decent.

Suggestions:

1/ Obviously mobile-first thinking, so the lack of any hover styles on desktop is a bit confusing. Desktop users are used to having some indication of functionality apart from the cursor.

2/ Ditto for lack of focus styles when using keyboard navigation. For most links, etc the only way of knowing where you are up to is the status bar.

3/ Would suggest having a global avatar resize, instead of restricting it to the header. Less gremlins to chase that way. My local test site currently has a whopping big avatar just so I can test this. Walloping things once is more fun, IMO.

4/ I think another break point would be handy. The av in the header tends to get a bit lost on your first break point. IMO he'd be better staying at the left until you get down a bit more in screen size. Also, I don't think there's any need to shrink him so soon, given that the links he sits with are staying the same size all the way down.

5/ Oh yeah, we can haz linky avatar? All the cool kids expect to get to their profile by clicking their avs these days.

6/ Header banner gets x-axis tiling at about 670px wide (fine above that).

7/ Desktop main menu drops could do with a bit of transition to make them less twitchy.

8/ Would be inclined to put the +/- pseudos in the sidebar on the relevant anchors instead of their parent li. First instinct with lack of hover style is to click the icons, which of course doesn't work. Same amount of code on the anchor or the li, and a bigger target won't hurt anyway.

9/ No idea what those icons on the message index and Display.template.php are supposed to mean. Does it come with a Rosetta stone?

10/ I like the posts layout, although my preference would be avatar at the left (no biggy). Same deal as the one in the header. I think he could stay left a bit longer. Maybe do them at the same break point. I can see the sense in sending them to the right once screen size gets down some more.

11/ Attachments handling is nice. Ditto reportlinks, quick reply, etc. Very smooth and clean. Ditto for info centre. Much better than standard.

12/ Quick moderation options on message index look clean, but are a bit confusing at first. Probably ok once you're used to it though. Could maybe do with some labelling.

13/ It plays nicely with my page index mod. Even without any associated CSS it looks clean and tidy (and could obviously be sexed up a bit if anyone wanted to).

14/ Aha. Went back to the theme change page in profile, to switch back to mutant Curve for more testing, and noticed you have a float clearing problem with the theme thumbnails. Should be an easy one to fix. I do like the styling of that page though.

[Bloc]

Thanks for your suggestions, Antechinus Some thoughts on the pointers..

1-2) I don't agree its mobile-first..more "device agnostic" or thats the idea anyway:) There are dropmenus, but the sidebar switch was a conscious choice. Not too sure about the hiding,at least not on desktops. Will prob. change. About keyboards: will check.

3-6) Still in the WIP area these..I am leaning towards making the theme less dependant on media queries and more "looking out-for themselves" type of css, meaning a type of thinking where every item is an island, it will never go beyond a certain width etc. If it does it will rather push down or transform. Not sure if this is the theme that will happen though. But tweaks are necessary still.

7-8) agreed

9) what icons..the topic icons?

10-13) the challenge is to make these appear nice on both desktop and mobile, not always an easy task. But tweaking will happen for sure.

14) Ah, forgot that one. (and prob a million others, there just so many darn templates to juggle with lol)

[Bloc]

Sounds nifty. Will have a look.

Hey I need to register to download. Is this a new site, or do I still have an old account there?

ETA: Nevermind. Grabbed it from ButtPlug and rezipped it myself. Now that I know what tricks it's up to, the workaround is a piece of cake.

Should work for guests now. I had forgot you have to tweak guest permissions on attachments when using reply-only permission profile.(that is, copy it and set it straight)

[Antechinus]

1-2) I don't agree its mobile-first..more "device agnostic" or thats the idea anyway:) There are dropmenus, but the sidebar switch was a conscious choice. Not too sure about the hiding,at least not on desktops. Will prob. change. About keyboards: will check.

Yup, I'm not so sure about hiding on desktop either. I think it makes sense as an automatic switch somewhere around 1024 screen width, because that's when standard SMF menus start to get a bit cramped for space. Above that I think you might as well use the available space.

Oh here's a thing I thought of last night: once the menus switch to hamburgers (on any theme) there's no visible notification of new PM's. That prompted me to add a link to PM's and an indicator as a text string up in the header, just below "Show new replies to your posts". It just says "My messages - ** new!" if there are new ones, and without the em tag and exclamation mark if there are no new ones. To save vertical space I put the current time string over to the right, just underneath the default search box.

The keyboard navigation shouldn't be a problem on Webkit (haven't tried Chrome yet) because IIRC Webkit forces their default outline styling on focus regardless of your CSS. Not sure about Android. It's definitely hard to tell where you're up to on Firefox or its derivatives.

9) what icons..the topic icons?

The buttonlist functions. Cute icons. Look very stylish. No idea what they do though.

14) Ah, forgot that one. (and prob a million others, there just so many darn templates to juggle with lol)

I've been getting rid of floats in as many places as I can, and using other tricks (inline-block, text-align, absolute, table-cell, a bit of flex here and there, etc). Floats can be very irritating. Good thing about inline-block (and table-cell and flex) is automatic RTL support.

By the way, here's a funny story for you. Remember me banging on about how I liked click menus a while back? I've been doing basic CSS tweaks to Curve's default drops, and have discovered that I quite like them once they have had a bit of obedience training. I opened up the old Apocalypse thing last night to check some of the code I used in that, and was finding the roll-down click menus annoyingly slow.

All I've done to Curve's ones is put a transition on hover ( transition: left .1s step-end; ) so they don't flash when scrolling past on the way to other things (wouldn't be relevant on touchscreen) and a delay on mouseout ( transition: left .25s step-end; ). This vastly improves the behaviour of the default menus. For example, when tracking between second and third level drops you can just mouse diagonally, straight to the link you want in the next level, without the menus twitching. The slight delay on opening (roughly equivalent to human reaction time anyway) means there's no problem with multiple drops opening on scrolling past links either. Basically they open as soon as you stop on a link, but stay closed if you're just going past.

Funny how trying different things alters your perspective.

[Bloc]

Ah yes, the buttonlist. The idea was, well, to get as many buttons on one line as possible, BUT, the symbols are kinda confusing for some I think(even me and I picked them lol)..so a better alternative might been just a big click-button that puts up a clickable menu. Of course it means a extra click/touch but at least you can get the labels in there. Gonna try some stuff with that on next version.

"transition"..thats a interesting one, only been using it once or twice since its quite new I think - or at least new to me - but it does a few tricks, have to check your suggested code because the menu thing is quite annoying if you have 2-3 sublevels. In my main menu I used fullwidth subitems to counter-act some of that annoyance, so you WILL hit the subitem even if you get outside the immediate subitem area. Its less practical on second and third level menus, unfortunately.

[Antechinus]

I think click could work quite well there, once the screen gets smallish. Often people don't use the buttonlist functions anyway. I think it's more common to use the quote function or the quick reply, and those are always visible, so if reply and the others needed a click I don't think it would bother anyone much.

Droplines are a bit awkward to use imo. A standard drop means you just trick straight down, whereas with droplines I find that the right angle turn then mouse to target is not as natural. Wouldn't be a problem on touchscreen or via keyboard, but is a bit funny with a mouse.

Third level drops can be awkward, but since I've managed to get them sitting nicely while I just mouse diagonally I'm finding them ok. One problem with third levels is they tend to run out of space on narrow screens and can overflow to the right. But then you can just use the second level for the sake on one more click, which is arguably not going to take any longer than tracking to the third level.

[Antechinus]

Had a thought about this. I may even use it myself.

With the buttonlist, I think "Reply" is the only one that gets much use. Obviously that's based on the way I use the thing, but I'm guessing I'm a fairly standard model human. If that guess is correct, then you could just have the Reply button showing and a hamburger (or whatever) next to it, with the rest of them stashed in that. With a text label on the hamburger, of course. Can be hidden for sighted users (text-indent: 100%; overflow: hidden;) or you could skip the hamburger and just have a text label like "More options" with a little pointy pseudo attached. Most people most of the time would probably find that just as convenient even on desktop, and it'd free up a lot of space on phones.

[Bloc]

Yes, it would make sense to go down this road, because you can make tiny buttons without labels for mobile but its a loosing game once mods add their own into this(which prob. won't even have defined icons on them).

[Antechinus]

I have heard quite a few grumble about icon menus. People tend to like being told what things do before they try clicking them all.

[iMiKK]

Nice work!

[Bloc]

v1.22 released with various fixes in mobile view, changed behavoir in buttons and more.

This is primary a "tweak&fix" release for glitches that have popped up. Not tested with any mods so far, but if anyone notice anything: give me a hint.

DEMO & Downloads:
https://bhksite.info/bdownloads/index.php?refreshme

[Biology Forums]

Thank you!

[Antechinus]

Cool. Will take a look.

[Mick.]

Very sweet bruh! 

[Antechinus]

Looks good. I like the way you've handled the main menu (expanded submenus when hamburgered). That makes a lot of sense. It's consistent with the "internal" sidebars and should play well if anyone has coded a second level of drops on their main menu (haven't checked, but assume it will handle that).

Handling of the .buttonlist strips and up/down buttons is also excellent. Not so much the next/previous buttons, I think they need more distinctive styling to make it obvious which half does what. I'd split those into two buttons, or if styled as one bullet have a central divider.

Noticed that your textarea for replies (full replay page) is breaking out of the screen with Pale Moon, even on quite wide windows, which means it probably will with Firefox as well. This is with the bbc editor set, not the wysiwyg. Quick reply is fine. It's only the full reply page that breaks.

Also noticed you've used a trick that I just "invented" myself last night. Setting a max-width on the large inputs in vw is the only way I found that will make them behave. Anything else insists on breaking, one way or another. Shouldn't need it for textareas (I have those sorted without it) but it would probably work for them too.

Oh, and what do the top level icons do in the profile/admin sidebar now? They're clickable, but nothing seems to happen.

[Antechinus]

Ah. Found bug. On ?action=unread;all;start=0 it's showing all the threads as "Awaiting approval" instead of "New". There doesn't appear to be any "New" link as such.

[Bloc]

Great, another bug(or several) lol. They never seem to stop do they?

Uhm, what trick was it that you invented? tbh you lost me there..something about the textareas?

[Antechinus]

No, the .text_input class. I was presumably struggling with the same problem you had, and happened to come up with the same idea last night. The inputs in the .settings dl's seem to be ok, but inputs directly inside an li seem to want to push breakage no matter what you do, unless you max-width them with vw. Made me do a bit of swearing until I thought of it.

Doing these little projects makes it clear how bad 2.0.x is for responsive in default form. Fair enough, it was conceived when IE6 was awesomesauce and before responsive was a thing, but strewth it's a pig's breakfast. Even down to really silly little things like having colons hard-coded in the markup, separate to the language strings they come after.

That's just mental, because even if you aren't doing responsive you might want to change the bloody presentation but no, some defiler of virgin goats has effing hard-coded colons everywhere. You want a hyphen instead? Tough luck, sunshine.

You want to mess with this new-fangled responsive stuff, and cleanly break labels to a separate line with display: block; on narrow screens? No can do, boyo. We're going to leave colons jammed up your colon all over the place. When you have to do multiple template hacks just to deal with stray colons it really is getting ludicrous. They're punctuation. They should be part of the language strings, like any other punctuation.

And another thing! #&&@^@#%! How about you want to cleanly break some stray bit of text, like a percentage count in a poll or something, to a new line with display block? You're screwed there too, because it ain't wrapped in a convenient HTML element so there's no way you can target it without hacking the template! Yay!

And speaking of targeting, now I'm on a roll, WTF is with the same parent ID being shared for several areas of profile or admin or whatever? If they're all frigging "admincenter" then how the flying snot dollops can you use those for accurate CSS declarations if you need to style a particular subaction differently? Heaps of id tags floating around, but hardly any of them are any actual use.

[Antechinus]

Hey I just noticed something while taking a quick look around 2.1. It's not actually responsive. Not really. For example, if you're on a desktop the menu will stay on the default desktop menu regardless of window width. This means the so-called "responsive" menu is not responding to screen size, but is instead relying on user agent sniffing (or something similar) in the back end coding. Which makes me wonder if the loading of "responsive.css" works the same way. If it does, that would be nuts.

Take the example of someone with poor eyesight using a desktop. They will want the text magnified significantly, possibly up to 300% standard size. This is going to throw all sorts of borkness at a standard layout, and if "responsive.css" is not available then you have an a11y problem. Which is why I prefer to set break points for responsiveness in em: because then the layout is matched to the desired text sizing.

[Antechinus]

Actually scrap that last post. I found out the menu doesn't come in until screen width is down to 480px. I expected to see it sooner than that. So it's not relying on back end sniffing, which is good. But the point about setting break points in em still stands. If you zoom text size with break points set in px, they remain inoperative. If you set them in em (or even in rem if you prefer) then the layout fits the content much better.

[Bloc]

Hehe, the colon stuff is not actually a "thing" - until it is, and of course its right when you are making some new templating stuff. In fairness, not all can be attributed to lack of forward vision, its just whats was there and seemingly doing fine at the time...but of course its annoying NOW.

So you mean we should set breakpoints in em/rem instead of pixels? Makes sense, they are just after all pixels at some point anyway, a degree of whatever default text size is. Have to try that. Thanks!

[Antechinus]

I don't know if everyone thinks we "should" set break points in em, but it's seemed like a no-brainer to me for years. This may be down to the fact that I only rarely browse on mobile, so am not naturally mobile-centric in my thinking.

Back when media queries first came out everyone was thinking "Hey cool, now we can fit stuff on tiny phones". OTOH I had been swotting up on a11y stuff and one of my first thoughts was "Hey, now people who need to magnify text will be able to fit stuff on desktops or laptops". It works brilliantly in all three cases, for exactly  the same reason: it arranges layout according to content. When you think about it, media queries on phones are a way of making stuff that cannot be made smaller (IOW, stuff people need to read) fit in a sane layout on limited screen width. So, if you're on a 1280 laptop and you require 24pt text for it to be easy for you to read, then effectively your screen is a 640 in terms of what you want to fit on it.

[Antechinus]

Hey I was just thinking of something. Since we both decided to mess with error log markup, what do you reckon is the most sensible hierarchy for the error stuffz?

At the moment it has member name and IP all bold up the top, but it got me thinking that this isn't all that useful a lot of the time. Most errors are things like undefined index or parse errors. That's usually what you want to filter by first.

Member name and IP are only really relevant for occasional things like brute force attempts on admin login, or some script kiddy trying a hack which hasn't worked since 1993.

So maybe it'd make more sense to rearrange the log entries to have "Type of error" and "Undefined index: ******" in the top row, with file name and line number under that, and member details last.

[Biology Forums]

To be very honest about the theme in general is that I really don't like the long search bar on the left when in desktop view. It's a little too much, and a lot of space is wasted on the left. Have you considered making the length of the bar smaller?

[Bloc]

To be very honest about the theme in general is that I really don't like the long search bar on the left when in desktop view. It's a little too much, and a lot of space is wasted on the left. Have you considered making the length of the bar smaller?

I am not quite following - the seach bar is not taking up much space in height. If you rather mean the whole sidebar and its empty space? Thats staying, but the plan is to have more items transferred there from the main view/area.

[Bloc]

Hey I was just thinking of something. Since we both decided to mess with error log markup, what do you reckon is the most sensible hierarchy for the error stuffz?

At the moment it has member name and IP all bold up the top, but it got me thinking that this isn't all that useful a lot of the time. Most errors are things like undefined index or parse errors. That's usually what you want to filter by first.

Member name and IP are only really relevant for occasional things like brute force attempts on admin login, or some script kiddy trying a hack which hasn't worked since 1993.

So maybe it'd make more sense to rearrange the log entries to have "Type of error" and "Undefined index: ******" in the top row, with file name and line number under that, and member details last.

Sounds logical, currently I am working on other areas and haven't really delved into it yet.

[Biology Forums]

To me a little more clear, here's what I mean.

The sidebar is too wide. More emphasis should be put on the right side. Furthermore, I have an issue dedicating 1 line of real-estate for the open-id image.

[Bloc]

I respect that you feel that way - but its not necessarily things I agreed with.

The sidebar width is fine as it is, it was a consideration after all, not something randomly chosen. The OpenID icon is a bit alone there, but it will probably be added with a text next to it.