What I think needs to change in the UI

[lizmat]

@Altai-man hope you're doing well!

As you may have seen, I've been pretty busy the past weeks.

It's getting to the point for me to get to a final push to get the beta version live. But I think a number of things need to be tweaked still. Some of which are currently beyond my JS / HTML / CSS capabilities. I hope you will be able and willing and having the time to help me with that.

1. I think you have finally sold me on the 3 column approach. But with a twist: the left column should always be about the search options, and should be hidden by default. The right column should always about filtering messages, and be hidden by default. And not shown at all on the home and index pages.
2. The calendar is too big for use in search options: I think the default rendering of type="date" should be sufficient, but some CSS / event magic prevents me from doing that.
3. The calendar should not be part of the filtering options. It is not a filter. I think the calendar in its current form should maybe only used on the home page for each channel, and maybe on the index page of a channel.
4. The current calendar rendering should appear when hovering over the date on the day view.
5. On the day view, the < date > should always be in view, and not be part of scrolling of the messages.
6. I can't get some of the pulldown menus to disappear again if the action is a Javascript action. Should this be a matter of adding the is-hidden class to some element?
7. I don't like the way the common.crotmp template has grown to basically be all pages. I think this needs to be more of a library, with just subs to be called from it. Is there any reason not to do it like that?
8. I'm still not sure where we would put the information that was previously in the &footer. I just want that information somewhere, not necessarily a <footer> element, which I just learned has special semantics.

I'd like your feedback on these issues if you can! Thank you!

[Altai-man]

Hi! Thanks for pushing this forward when I am nearly non-existent. :)

First, I will ask you to revert one kind of a change: please, move the Camelia logo / home url back to where it was. Placing home at the upper left corner is basics of basics, it is unheard of to move it to the right. See Github, Google, Amazon, Facebook, everyone. https://www.nngroup.com/articles/homepage-links/ <- basically this.

I also see your changes to the header completely broke the mobile view, I'd say we need to consider reverting them. That's why I am in general against people spending precious time on something which can be delegated instead.

Now back to your suggestions.

I think you have finally sold me on the 3 column approach. But with a twist: the left column should always be about the search options, and should be hidden by default. The right column should always about filtering messages, and be hidden by default.

I think this needs to be elaborated about your reasoning for this. As I understood it, you want to put up a right sidebar with options we now have on the search page (?).

So do you suggest to get rid of the search page and instead integrate search options into day page? But what about URLs to search pages to share? And if you don't want to remove the search page, then this functionality will be duplicated? I don't think you want a SPA-like architecture, but instead going for a more traditional way with functionality separation sounded like a general target for me, but now you suggest moving toward page cluttering the non-SPA pages handle badly?

Keep in mind this will also make the mobile view inconsistent and will likely put some additional burden on you and me, I'd have to call the designer in, sponsor, all that.

The calendar is too big for use in search options: I think the default rendering of type="date" should be sufficient, but some CSS / event magic prevents me from doing that.

I am sure this is a bug, on the original mockup it looked as you want and then we broke it along the way, it seems.

The calendar should not be part of the filtering options. It is not a filter. I think the calendar in its current form should maybe only used on the home page for each channel, and maybe on the index page of a channel.

You are correct, the calendar is not part of the filter options. I would move it higher so that it would be above the filtering options and added a hr between them to show a separation.

The current calendar rendering should appear when hovering over the date on the day view.

Why? If by the "the date on the day view" you mean the title text you added in the header, I'd say it is kinda redundant on its own. On a mobile view there is no header to show it and on a wider screen most users won't hide the sidebar and will see the date there.

On the day view, the < date > should always be in view, and not be part of scrolling of the messages.

On small screens there is no header and on wider screens people in general will have sidebar shown with a better date selector.

I can't get some of the pulldown menus to disappear again if the action is a Javascript action. Should this be a matter of adding the is-hidden class to some element?

I need a specific example, I think.

I don't like the way the common.crotmp template has grown to basically be all pages. I think this needs to be more of a library, with just subs to be called from it. Is there any reason not to do it like that?

Whatever floats your boat. I would not strive for this. Maybe you see it from the perspective of "libraries" (common code) and "apps" (usages), but from my perspective templates are NOT code and there is no obligation to organize it like code, so I don't see a lot of merit for a small number of pages we have on this website. I mean, we don't have a lot of duplicates except for day/live.

I'm still not sure where we would put the information that was previously in the &footer

What information?

[lizmat]

Hi! Thanks for pushing this forward when I am nearly non-existent. :)

Well, I hope you are very much existent, just not very visible :-)

First, I will ask you to revert one kind of a change: please, move the Camelia logo / home url back to where it was. Placing home at the upper left corner is basics of basics, it is unheard of to move it to the right. See Github, Google, Amazon, Facebook, everyone. https://www.nngroup.com/articles/homepage-links/ <- basically this.

Well, I'm not going to die on that mountain. To me, consistency in UI has always been more important than adhering to some rules. And knowing who your audience is. So I will move it back :-)

I also see your changes to the header completely broke the mobile view, I'd say we need to consider reverting them.

I think it should be fixed. This could be by me understanding how this works and fixing it. Or somebody else fixing it.

and will likely put some additional burden on you and me, I'd have to call the designer in, sponsor, all that.

Can you explain why we would need a designer still, now that we have a basic design? Or is this the person needed to tweak the *.scss files? If it is the latter, why can't we do that ourselves? I'm really just trying to understand the roles of people in all of this!

That's why I am in general against people spending precious time on something which can be delegated instead.

Delegation only works if there are people to delegate to. For whatever reason, and I'm NOT blaming you, there weren't any available the past weeks. And I wanted to move forward. And I've learned a lot. Even though maybe it won't show up in the result. I've always seen a successful product as a nice side-effect of the creation process. As long as I've been able to learn stuff along the way, it is good :-)

I think this needs to be elaborated about your reasoning for this. As I understood it, you want to put up a right sidebar with options we now have on the search page (?).

If you go to /channel/search.html, you will see the search options in the left. I think these should be there on all pages: /home.html /channel/index.html /channel/yyyy-mm-dd-html /channel/live.html /channel/gist.html. The "Filter" options should be on the right hand side in all of these pages except /home.html and /channel/index.html as these do not show any messages, and thus have little to filter on. If we put the Calender at the top of the Filter section, then that could be shown on /channel/index.html. The Calendar doesn't make any sense if no channel has been selected, so should not be shown on the /home.html page.

Does that make it clearer? The most important thing in this change, is that you should also be able to filter on the search results page, and you currently can not.

So do you suggest to get rid of the search page

No, but it is the search results page.

and instead integrate search options into day page

No, not instead. Search options should be available on all pages. Mind you, the default for the left bar with the search options, should be to be invisible. One would have to activate the search options only if wanted.

then this functionality will be duplicated?

Yes: you should be able to initiate a search at any page for any reason without needing to go to another page. The reason for this is that you probably want to copy / paste one or more things from the page you're looking at (e.g. a nick and a text).

I don't think you want a SPA-like architecture

Could you elaborate on what you mean with a SPA-like architecture in this context? I have some images with that, just want to make sure we're on the same page here.

Keep in mind this will also make the mobile view inconsistent

Do we want the mobile view to be able to do searches? I'd say yes. Do we want the mobile view to be able to filter the messages client-side? I'd say, yes. Will that make the mobile view hard? As long as we create two pull downs for the minimized left / right columns, it should be doable. But I guess that would be against some UI rules? Then I guess just a single exploder, with all the options then.

I am sure this is a bug, on the original mockup it looked as you want and then we broke it along the way, it seems.

That's very possible.

You are correct, the calendar is not part of the filter options. I would move it higher so that it would be above the filtering options and added a hr between them to show a separation.

From a user perspective, I think the filtering options are more important than the calendar. And again, the Calendar looks nice, but only really makes sense in a "day oriented search mode". And that is really only the case when on a /channel/yyyy-mm-dd.html page. And then only if one wants to go to a date other than the next or previous date. Hence my argument for putting it with the date, maybe not with hovering, but with a little calendar icon next to the > chevron. Moving to a specific date from any page showing messages, can be done from the ... pulldown of a message.

Why? If by the "the date on the day view" you mean the title text you added in the header, I'd say it is kinda redundant on its own.

I showed the server to a number of naive users, and the first thing they said was that they couldn't see on what sort of page they were. The little icon was not enough, hence the "redundant" mentioning in the header. In the mobile view, the icon should be enough, since there simply isn't any room for anything else.

On small screens there is no header and on wider screens people in general will have sidebar shown with a better date selector.

You don't make it easier to go from one day to the next or previous by forcing people to use the calendar. I want people to be able to scan through the messages of a day, and then simply select the next day without needing to scroll all the way up again. Trying to find the current date in a calendar and then needing to find the next one (especially on week and month boundaries) is just cumbersome.

I can't get some of the pulldown menus to disappear again if the action is a Javascript action. Should this be a matter of adding the is-hidden class to some element? I need a specific example, I think.

The "Add to gist" option in the ... menu of each message. Or the 2nd, 3rd, 4th option in the Gist menu.

I mean, we don't have a lot of duplicates except for day/live.

Ah, but we do :-) And a single duplication would be enough for me externalize it into a sub. So that the interface can be easily kept consistent if it changes. Having two identical pieces of text (whether they be code or template) in two different places, is just a maintenance nightmare waiting to happen.

I'm still not sure where we would put the information that was previously in the &footer What information?

How the site was made, with Cro and Raku and stuff.

[lizmat]

@Altai-man

• moved camelia back to where it was
• fixed the mobile view, so far anyway

[Altai-man]

To me, consistency in UI has always been more important than adhering to some rules

Well... This is an interesting point. You are correct it is really important to have a website content put consistently, I wholeheartedly agree with this. OTOH, a web page is just a "page", one of billions of such pages. People are prone to making patterns to apply when using a thing and those patterns form their expectation, then comes the usability (rather ease of understanding of a new thing, how natural does it feel). A layout may be sensible on a single website, but if 1000 websites the user visited prior to that did a thing in X way and the site does it Y way, this higher level/perspective of consistency (not within just a single page, but within Web in general) wins any day.

In a sense, I see a good design not in a "X is X, so it should be here, a bunch of Y should be there" sense, but in a "The user expects X to be here and likely a bunch of Y there, so let's go the way of the least surprise for the user" sense.

I am not saying your idea to move the home link to the right is that horrible, I am just speculating about the "internal consistency VS external consistency", here comes the metaphor. Say you sat on 1,000 chairs before and then you encounter one which looks fine but will break unless you set up the seat before you use it. Even if the creator thinks the setting it up is important for internal structure of the chair, as a user you will be really surprised when you get to know it doesn't behave like 1,000 chairs you saw before that.

People do not create some flaky "UI rules" to shame others and "We will do it because cargo cult", it is more of a result of people observing how people expect things to work and saying "People think the home URL will be there, so let's put it there".

Can you explain why we would need a designer still, now that we have a basic design?

If you plan major changes like pulling the search controls to the day page, the mobile view will be overwhelmed. I don't think I can get a solution and I am not sure if you have one either, that's why my idea to make it move is to ask somebody who can think of something.

UPD: reading what you suggest further, in a way just hiding the search sidebar on mobile view works and then we don't need external help.

Delegation only works if there are people to delegate to. For whatever reason, and I'm NOT blaming you, there weren't any available the past weeks

I think we got a bit of communication breakdown here, maybe. My plan on this was (very generally):

• You wrote the code, that's fantastic.
• I bring the UI templates for us
• We wire it together with the code, fill in JS bits
• Release

What happened from my POV is:

• You wrote the code, that's fantastic.
• I bring the UI
• You don't like it and start to rework a lot of things
• Because I assume you are working on re-taking the UI, I don't spend my time with other things like JS bits, which come after the templates are set in stone.

Does that make it clearer? The most important thing in this change, is that you should also be able to filter on the search results page, and you currently can not.

Yes, I see your idea now. That's interesting, I'll need to think about it for a bit, on the first glance it sounds nice.

Could you elaborate on what you mean with a SPA-like architecture in this context? I have some images with that, just want to make sure we're on the same page here.

Well, in Web 1.0 we have pages obtained with GET and POST requests. So a "normal" search workflow would be:

• Get a search page with GET
• Type the data, send a POST
• Get the search page + results
• ... repeat if needed

With a Single Page Application this workflow omits the server page rendering side. The code to present all the pages is downloaded once and then the user navigates the JS driven pages and the only interaction happening between the client and the server is pure data exchange. Why I brought it up is because I thought you want the day page to serve as a search, so that for example search results will be loaded on the same day page, which would then be kind of a mix between what we have now and poor man's SPA. But after your clarification I see I misunderstood you and what you are suggesting is basically increasing the number of search forms across the pages we have, that's far safer than what I thought at first.

Do we want the mobile view to be able to do searches? I'd say yes. Do we want the mobile view to be able to filter the messages client-side? I'd say, yes. Will that make the mobile view hard? As long as we create two pull downs for the minimized left / right columns, it should be doable.

As I noted above, on mobile screen there is not enough space to have both sidebars, that's why I am concerned they need either something smart like a switch or no search sidebar at all.

From a user perspective, I think the filtering options are more important than the calendar

Calendar is our primary navigation between days, so I am not sure about that, hmm.

I showed the server to a number of naive users, and the first thing they said was that they couldn't see on what sort of page they were.

That's interesting insight. "What sort of page they were" - can you please elaborate? Was it hard to differentiate between Search page, Day page, Live page or Index pages? Or do you mean dates? Was the sidebar with the calendar visible for them?

You don't make it easier to go from one day to the next or previous by forcing people to use the calendar

You are be right, I see your point.

Ah, but we do :-)

It's a waterbed of complexity case of situation. Templates are not imperative code, but a markup, so factoring out should be used very carefully IMO. E.g. when someone reads the markup they imagine/visualize how it looks and if too many blocks are hidden somewhere else and there is a need to do a jump instead of understanding everything at a glance it becomes easier to do mistakes.

Say if you have your code factored into normal size subs and it works nicely, but if every 2 lines of code reside in their own sub and you want to understand what is happening in some details I'm calling the police. And with markup it is especially important, because of how different blocks interact with each other, so changing A can broke B somewhere down the line.

Too many subs is as bad as too little.

How the site was made, with Cro and Raku and stuff.

I think it is there, no? Currently we say it was made with Raku and Cro and suggest to post issues, what's missing?

[Altai-man]

TL;DR:

• I mis-thought you want something more massive
• Your take on search sidebar and changes to navigation sound interesting, but we need to think carefully how to place it so that it looks well.
• I will revise a couple of issues you noted (search page calendar bug) this weekend.

[lizmat]

it is more of a result of people observing how people expect things to work and saying "People think the home URL will be there, so let's put it there".

That's true, but I wonder how much of this is culturally dependent. I wonder how people that are used to a language that goes from right to left, expect the home button to be on the far right corner :-) But I see your argument.

we don't need external help

I don't think we do :-)

As I noted above, on mobile screen there is not enough space to have both sidebars, that's why I am concerned they need either something smart like a switch or no search sidebar at all.

I've just committed some changes that made the mobile menu more compact. I think I can do the same for the search options tomorrow.

Calendar is our primary navigation between days, so I am not sure about that, hmm.

I've put the calendar at the top of the right bar now. But I think that gets confusing on the day view. The calendar should only be visible when one needs to go to a specific date. If it would be under a calendar icon next to the date, then that would automatically also become available in the mobile view of the day.

With regards too too many subs: I realize too many subs do not improve readability. I will try to keep the waterbed functional, and not leak too much :-)

I think it is there, no? Currently we say it was made with Raku and Cro and suggest to post issues, what's missing?

It's currently not shown at all because I disliked the fact that it is over the complete width of the viewport, and with the search / filter options shown, you only see part of the footer. I think it needs to be either always visible completely, even with sidebars open, or only visible in the middle column.

I will revise a couple of issues you noted (search page calendar bug) this weekend.

Cool! I intend to work on Friday on:

• making search options work on all pages
• creating a mobile version of the search options
• getting the "live" functionality to work

Will let you know how far I got.

[Altai-man]

It's currently not shown at all because I disliked the fact that it is over the complete width of the viewport, and with the search / filter options shown, you only see part of the footer. I think it needs to be either always visible completely, even with sidebars open, or only visible in the middle column.

Hmm, I think I pushed a fix for that, no? Maybe it broke with introduction of right sidebar, hmm. I'll take a look.

getting the "live" functionality to work

You likely want to use a websocket connection for that, on the raku side it needs to use websocket route handler from the Cro and then you emit freshly added messages there, and on JS side a new connection will be opened, then it listens to new events and when "New message" appears a HTML is constructed and inserted. Ping me if you need more specific examples.

[lizmat]

Ping me if you need more specific examples.

Ping :-)

[Altai-man]

Don't mind me, I am just a list of things to do.

• [x] For the third time footer was broken, make it behave well as in 1)take the whole width; 2)be above sidebars; 3)not to mess up text with smaller screens.

• [x] Dropdowns for Gist and Browse behave badly on smaller screens

• [x] The color of Submit button on mobile view is wrong

• [x] Add a separation between the Camelia icon and channels list
• [x] Move date, <, > buttons and nice dropdown date picker into the header

[lizmat]

Ok, I'll do some other stuff the coming day(s), like moving all of my modules to the zef ecosystem.

[Altai-man]

Alright.

About:

Ping :-)

Can you please write where can I async-y stream the messages for "live" on the backend? I think I can do the "getting the "live" functionality to work" bit, maybe that'd be easier.

[lizmat]

App::IRC::Log has endpoints for /channel/scrolldown-html and /channel/scroll-up.html that I was thinking of using before you mentioned WebSockets. Is that what you mean?

[Altai-man]

Thanks, I'll look at them.

[Altai-man]

I have an impression we addressed points in this ticket, have we not?

I remember our previous conversation about 2 bits:

• Closing the message menu after a button is pressed
• Making padding between two same-nick messages smaller.

The first one maybe can be tinkered (I wasn't able to do it off the bat, hence the delay), but both ways work just fine IMO. Maybe the current behavior is even more intuitive.

About the second bit, I looked at it and IMO it's less readable than the current one, compare https://ibb.co/KrT4zqz and https://ibb.co/fD7qdKF

And for other bits we can create new issues, notably mobile view is not awesome currently for the home page (it was edited and IMO has changed for the best, thanks @lizmat !) (I asked for some minor tweaks for this page).

[lizmat]

@Altai-man to get the live functionality going, you need something to change the log file of the last date in your logs. You could write a program for that that would just .spurt(:append), that should be enough. To get a "real" live feeling, you'd need to run a logger: but that would be basically doing the same, but you'd have to wait for people to actually say anything :-)

[lizmat]

Re: live behaviour: I was thinking on disabling the timed behaviour if the browser is not in focus. If it is, then it should do a scroll-down action. If people really want live behaviour, they should use an IRC client. If you could get a physical scroll-down logic working (using the Y position or something, like the upscroll), then that would be a nice bonus.

[lizmat]

@Altai-man Re reduction in padding: if I look at those screen shots, it looks to me that all lines are closer together. What I would like to see (in ASCII art):

Current situation:

lizmat       This is a message                               15:37   ...

             This is another message by me.                  15:39   ...       

sena_kun     A message by Altai-man                          15:41   ...

What I would like to see:

lizmat       This is a message                               15:37   ...
             This is another message by me.                  15:39   ...       

sena_kun     A message by Altai-man                          15:41   ...

Does that make it clearer?

[ogdenwebb]

Hi, @lizmat. Regarding the layout you suggest:

The current layout of the message log is very straightforward, it doesn't group messages in any way, allowing the backend to just supply a flat list of messages. The bad news is that it doesn't allow us to style an element based on a relationship between the "parent" message and its same-nick children easily.

I think we still can write a rule for normal (non-system) messages to add the extra padding after a row with special-same-nick class. It's still a work in progress, but hopefully it'd help us to get the desired behavior.

[lizmat]

Closing this now. Please reopen if you think it should