[Jerry Jr. Ortiz]

Introduction

As AndalayBay suggested, I've opened up a separate thread for discussion of changes to the BOSSlog to stop it filling up the main BOSS thread and taking attention away from mod reports, and to hopefully get some more input from BOSS users that don't necessarily follow the main thread.

http://dl.dropbox.com/u/17043363/BOSSlog165.html (the latest release).

http://dl.dropbox.com/u/17043363/BOSSlog.html, which will be released at some point, hopefully sooner rather than later.

The link for the v1.7 BOSSlog will always point to the latest iteration of the log.

I'd like to hear your thoughts on the new format and am open to any feedback/proposals you might have.

BOSS v1.7 is actually in a state where it was ready for release a couple of months ago (waiting for Wrye Bash 292), and all these log changes were scheduled for v1.8. Since they're all HTML/CSS/Javascript-based and so don't impact BOSS's execution code they're safe enough that I can make the changes without having to go through another testing cycle, allowing me to make more improvements before release. I'm not making any more changes that require execution code changes. As such, not everything I agree to put in may make it into v1.7, but if I say something will go in, it will be in for v1.8.



Needing Discussion

• Having a summary at the top of the BOSSlog. Opinions? What should go in it?
  
• Colour-coding of message types besides warnings and errors? Should all message types have their prefixes colour-coded? If so, what colours?
  
• Do messages stand out from their mods enough?
  
• Is the log easily readable?
  
• Do all the log's filters and collapsible sections work in your web browser? (Confirmed working for Firefox 4, Google Chrome 11, Opera 11, Internet Explorer 9)

Some Reasons For The Changes

Filters

These allow the user to pick and choose what is visible in their BOSSlog, so they can cut out stuff they're not interested in, making it easier to see the important stuff. I don't think there's any downsides to them being there, so there's not much more to say.

Collapse-able Log Sections

Those minus signs to the left of the BOSSlog section sub-headings mean that the section is collapse-able, so clicking on the sub-heading will hide its section, and the minus will turn to a plus. This is again a feature for hiding information the user is not interested in, and for saving the user from more scrolling if, for instance, they only want to see what mods were unrecognised.

Colour-coded messages

Green = OK, Orange/Amber = Warning but not serious error, Red = Serious Error. Previously only Error messages were coloured (in red), but the addition of the green colouring sends a clear signal to users that they don't really need to read the information. The message types and their colours can be seen listed under Oblivion.esm's entry in the v1.7 BOSSlog.

OBSE & OBSE Plugin Checksums

Not a format change, but people might ask questions about this new section, this is only displayed when you run BOSS with the --crc-display, -c flag set. It's sole purpose is for people to see what the CRCs for their OBSE plugins are, as this information can be used in the masterlist. So it's primarily a BOSS team tool, but visible to anyone who wants to see it. Not much more to say.

Ghosted, Version and Checksum Labels

These were all given background colours to distinguish them from the rest of the text. The Checksum information is new, it is only displayed if BOSS is run with the --crc-display, -c flag set. People said that the background colours made the labels stand out too much, so I turned their background colours into their text colour. The result is that they are still distinguishable but not in-your-face. Although the labels might be too light to read for some people now.

Non-Bolded Mod Names

The old BOSSlog used bold to highlight mods with messages. Some people complained about the formatting inconsistency with the rest of the mod names, and I agreed. I had set all the mods to be bolded, but this gave emphasis to the wrong parts of the BOSSlog, as the messages are important, not the mods, since messages might have to be acted on, but mods never do. I still needed some way to differentiate between the mods and their messages besides the indent, and so I italicised the mod names. Then those with visual impairments complained, so I got rid of the italics too, and just increased the amount of indent slightly. Hopefully that should be enough.

More Spacing

The introduction of colour to the BOSSlog meant that more spacing was required to stop the colour from 'bleeding out' into the surrounding text. In addition, I feel that the old BOSSlog didn't give enough spacing between sections of text, which would lead to the text being harder to read. I actually slightly decreased space between BOSSlog sections, but increased the space below each mod's entry, visually weighting a mod's messages towards the preceding parent mod rather than the neutral spacing used previously.

Removal of "Unknown Mod File: " Text

The text was superflous given that the mods were appearing in the Unrecognised Plugins section, so I got rid of it. Less text to read without a loss of meaning is a good thing in my book.

Plugin Numbers

This is another new section that gives a few numbers relating to the user's mods. It's been proposed that this be moved to the top of the BOSSlog and turned into a fully-fledged summary section, which is something I'm interested in discussing.



Answered Questions

Q: What about being able to set defaults for the BOSSlog filters? Will we be able to do that?

A: Not for v1.7. I'm considering introducing an optional config file that will allow users to set defaults for various parameters for v1.8.

Q: What about the BOSSlog being a diff of what's changed since the last time BOSS was run so people don't need to read it if there was no change?

A: The format of a diff is generally counter-intuitive to the average user, I think, so it is unlikely. A simple message saying whether the output has changed at all since the last time BOSS was run is much more feasible and is something I can do. It won't happen for v1.7 though, because it would require more processing code changes than I'm happy doing at this stage in the release cycle.

[Alisia Lisha]

The new format looks quite pretty - Lots of whitespace and a cool color scheme. It's got my vote :thumbsup:

[Svenja Hedrich]

Hmm, I just realised that the orange used for the checksum badges is similar to that used for the warning messages, which kinda detracts from the latter's stand-out-ness. Looks like I'm going to have to find an alternative colour for the checksum badges.

I've updated the online BOSSlog with a few more unknown plugins listed and all the message types listed attached to Oblivion.esm as examples. This highlights a problem with the spacing of unknown mods, ie. they need more of it, as the badges for any one line and the next are just touching.

Since people didn't like the unknown mods having much spacing, I'll try to keep it a smaller amount than for the recognised mods.

[Angel Torres]

I like it - it's a huge improvement over the old one. The new formatting for messages is much better - it tells you more easily that X message belongs with Y mod, and the spacing overall is better, and the addition of color makes it more aesthetically pleasing while also serving to draw attention to areas that need it.

As far as the unrecognized mods, I'd simply put one line of blank space between each - it's enough to separate them without adding too much length to the file. I agree that "plugin numbers" should move to the top - if you have unrecognized mods, you'll know right off and can then scroll to the bottom to see what got missed. I was going to suggest making the hyperlinks (like the "Needs cleaning") actual links, but you've already covered that.

[adam holden]

For the new format:
Please for conflicts, errors, bad things not only red letters, the complete mod- line- background should be red and the letters with white colour.

Think of people with problems in visually recognizing colours.

The checksum is nice (and internally the right way to go), but is this such an import number (colour, marking).

EDIT:
Think of fast scrolling, ... scroll and scroll and scroll ... I have seen something big dark (red -> signal colour) ... scroll back ... read details.

[Mariana]

The new style looks great.

Regarding....

Q: Italicised text is hard to read for people with visual impairments. Would you consider changing the mod names to not be italicised in the v1.7 BOSSlog?

A: Yes, I would consider it, but you've got to give me a suitable alternative.

Given that the notes and tag suggestions are already indented, why not simply use normal text for the mod name - they will standout both from not been indented and from the version and checksum info.

[Marilú]

Put the Mod names in Bold? Should make it easier for everyone to read.

As I understand it, BOSS automagically assigns tags to mods? If so, would it be possible to turn off the display of tag suggestions?

[Emily Shackleton]

Not sure if this is possible but is there anyway you could highlight newly added mods since the last time BOSS was run so they are easier to find in the report? With an extensive mod list its sometimes hard to find that mod you have just added in the report so you can read any notes that BOSS suggests.I also agree with HeyYou that the mod names should be in bold.

[*Chloe*]

Put the Mod names in Bold? Should make it easier for everyone to read.

As I understand it, BOSS automagically assigns tags to mods? If so, would it be possible to turn off the display of tag suggestions?

I've nothing against this, so long as it is optional. I use BOSS in an unconventional manner, in its own folder (on a different partition than my playable Oblivion install) that houses nothing but BOSS, ESMs and ESPs. I use the BOSS log to manually adjust my playable Oblivion data folder, as well as manually add filters as needs. Admittedly, many newer mods requiring filters seem to come already-filtered these days. But I've installed a few that aren't.

-Decrepit-

[aisha jamil]

I don't really have a good suggestion for how to highlight the mod names as opposed to the text that follows: What will help one impaired reader will not help another impaired reader, it depends on the impairment in question.

Perhaps the suggestion to put them in bold might be the best answer.

[Juan Suarez]

I'd prefer all listed mods in bold also, but in lieu of that, would rather you just drop the italics and rely on the indent and spacing to suffice. It's interesting. Italics standardly represent emphasis or a title. You're using them for de-emphasis. It also made me ponder whether or not morerocks.esp is a title, like the title of a novel. If it is, then it would indeed be more stylistically correct to use italics. I don't think it is, though. I think the name of an .esp or an .esm is not necessarily the title of the mod. Underlining is traditionally equivalent to italics, but underlining obviously shouldn't be used here, because people would naturally expect any underlined text to be a link.

I do like darkstone's suggestion of highlighting newly added mods in some way. I also second WalkerInShadows regarding one space between unrecognised mods, but it sounds like some people strongly object. The checksum color runs together in your example.

[Solina971]

For the new format:
Please for conflicts, errors, bad things not only red letters, the complete mod- line- background should be red and the letters with white colour.

I'll try it out.

Given that the notes and tag suggestions are already indented, why not simply use normal text for the mod name - they will standout both from not been indented and from the version and checksum info.

Could do. I'll try this out too.

Put the Mod names in Bold? Should make it easier for everyone to read.

As I understand it, BOSS automagically assigns tags to mods? If so, would it be possible to turn off the display of tag suggestions?

Not sure if this is possible but is there anyway you could highlight newly added mods since the last time BOSS was run so they are easier to find in the report? With an extensive mod list its sometimes hard to find that mod you have just added in the report so you can read any notes that BOSS suggests.I also agree with HeyYou that the mod names should be in bold.

I don't really have a good suggestion for how to highlight the mod names as opposed to the text that follows: What will help one impaired reader will not help another impaired reader, it depends on the impairment in question.

Perhaps the suggestion to put them in bold might be the best answer.

I've already covered these in the OP. Mod names are highly unlikely to be bolded.

EDIT: Could people please read the OP? I've explained my choices and what's already been proposed there. I don't need people telling me to bold the mod names, and I don't need people asking for diffs. Both have already been investigated or considered.

EDIT 2: Should warning messages also be orange-background-highlighted, or should only error messages have that?

[josie treuberg]

I'm liking this very much :thumbsup:

Wrinkly if it helps any here's a post I did when looking into colour blind friendly for the Wrye Bash guide http://www.gamesas.com/index.php?/topic/1123302-wip-wrye-bash-pictorial-guide-for-newbies/page__view__findpost__p__16961714

The palette derived from that is a bit restrictive http://www.bild.me/bild.php?file=9518668ColourBlindFriendlyPalette.jpg

But each of those colours can be slightly darker or lighter, so long as it contrasts with any adjacent colour out of the range (and of course white). The Vischeck site linked in this post http://www.gamesas.com/index.php?/topic/1123302-wip-wrye-bash-pictorial-guide-for-newbies/page__view__findpost__p__17053131 is very useful
Also in that last linked post have a look at the two screens of the pictorial guide having been passed through Deuteranope and Tritanope filters

[A Boy called Marilyn]

I've updated the online BOSSlog, spacing out the unrecognised mods a bit, remove the italic effect from mod names, background highlighting warnings and errors, changing the colour of checksum badges to brown. I'm not happy with the new colour, but it was that or a green, which I couldn't get as easy to read from as the brown. Opinions?

The implementation of a summary will probably require more extensive code changes than I'm happy making right now, so that probably won't happen for v1.7.

I'm liking this very much :thumbsup:

Wrinkly if it helps any here's a post I did when looking into colour blind friendly for the Wrye Bash guide http://www.gamesas.com/index.php?/topic/1123302-wip-wrye-bash-pictorial-guide-for-newbies/page__view__findpost__p__16961714

The palette derived from that is a bit restrictive http://www.bild.me/bild.php?file=9518668ColourBlindFriendlyPalette.jpg

But each of those colours can be slightly darker or lighter, so long as it contrasts with any adjacent colour out of the range (and of course white). The Vischeck site linked in this post http://www.gamesas.com/index.php?/topic/1123302-wip-wrye-bash-pictorial-guide-for-newbies/page__view__findpost__p__17053131 is very useful
Also in that last linked post have a look at the two screens of the pictorial guide having been passed through Deuteranope and Tritanope filters

Interesting links. I don't know how much I will try to follow the information it gives though, but I'll try.

[Sara Johanna Scenariste]

Awesome, I hope people like the normal text mod titles. I think Surazal is right, emphasis may not be needed anymore with the new formatting. I wasn't suggesting you change your mind about bolding. I understand why you don't want to do it. Undue emphasis. I like the extra spacing a lot, and the color use is intuitive.

[Chris Johnston]

If you push as much as possible to the CSS file, you can let the users edit that for their own preferences (e.g. color-blindness, need different font size etc). The important part is to get the semantics right in the HTML you're formatting - i.e. don't use the same class for two different things just because they have the same visual aspect.

Note that the CSS can do some filtering in that you can use display:none to suppress things you don't care to see, as long as the class/ID allows.

If you push as much as possible to the CSS file, you can let the users edit that for their own preferences (e.g. color-blindness, need different font size etc). The important part is to get the semantics right in the HTML you're formatting - i.e. don't use the same class for two different things just because they have the same visual aspect.

Note that the CSS can do some filtering in that you can use display:none to suppress things you don't care to see, as long as the class/ID allows.

It's all done via the CSS