Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search bar expanding too much on click #277

Open
ardacebi opened this issue Jun 30, 2018 · 23 comments
Open

Search bar expanding too much on click #277

ardacebi opened this issue Jun 30, 2018 · 23 comments
Labels

Comments

@ardacebi
Copy link

Bug Report

Current Behavior
When I click to the search bar with a forum that has the links extension, the search bar expands too much and ovverides the links at the top.

Steps to Reproduce

  1. Go to home page.
  2. Click on the search bar.
  3. See error.

Expected Behavior
The search bar should automatically detect the width of the links and expand to only that part without ovveriding the links.

Screenshots
3564345643564356

Environment
Flarum Community

@franzliedke
Copy link

Thanks for the detailed report. 👍

@ardacebi
Copy link
Author

@franzliedke Was this a known issue or is this the first time you're seeing it?

@franzliedke
Copy link

Can't remember seeing a report like this, but then I've seen too many issues. 😉

@ardacebi
Copy link
Author

@franzliedke So, do you think this will be fixed by Beta 8 or later?

Asking because my forum visitors just don't like this and I got a few reports. I don't like it either. I know, it doesn't affect usability but it's still a bug 😄

@franzliedke
Copy link

I am not putting it on the roadmap for beta 8, because we do not want to delay that release any further.

You can make it happen by researching the solution and sending in a pull request, though. The joy of open source. 😉

@tobyzerner
Copy link

I don't think we want to fix it in the suggested way, the links on the left are variable-width, not to mention the window width, so you could end up with a situation where the search bar has no room to expand and stays small (especially problematic on tablet screen size where it is collapsed into an icon).

Tbh I don't think this is really an issue worth fixing, it's completely usable as-is. If we were to fix it we would need to think of an alternative solution - something like a search pop up.

@ardacebi
Copy link
Author

ardacebi commented Jul 1, 2018

@tobscure There are 2 possibilities.

First is to put a link limit to the links extension. So even if we apply this fix to the core, the search bar would never stay short and would expand in any condition.

Second is to change the search bar UI, replacing the search bar with a search bar icon at the top and when we click on it, the search bar will open at the top of the screen with a gray filter that gives the bar a focus.

This needs a fix, we can't leave it as is. I've been waiting to submit this report for months, now I had the time to do it.

If you also look at other people using Flarum in production, their forums has the same bug.

@dsevillamartin
Copy link
Member

This is not an issue with flarum/core. This bug is introduced with the links extension, and should therefore be fixed there.

However it's fixed in the links extension doesn't matter as part as core is concerned. There are definitely ways to change components in the Flarum front end, so it should not be a difficult task.

@ardacebi
Copy link
Author

ardacebi commented Jul 1, 2018

@datitisev So should this fix applied to the core or to the extension itself?

I don't think the extension won't have anything to do with the search bar, the core should detect that the extension is installed on the Flarum setup and allign the search bar width depending on that.

@dsevillamartin
Copy link
Member

Core only includes the bare minimums for the forum to function. Core should never, under any circumstances, act differently by itself if extension X is installed.
Extension X, however, can modify Flarum through the PHP & JavaScript API to its desire. Bugs introduced by extensions, if not applicable to multiple extensions and are not a bug in the core itself, should always be fixed in the extensions themselves.

@ardacebi
Copy link
Author

ardacebi commented Jul 1, 2018

@datitisev So should I submit this same bug report to the extension's GitHub repo for them to work on this and close this issue?

@franzliedke
Copy link

True. Unless there is a problem with the search bar without extensions, then there is nothing for us to do. (Unless @sijad comes along and proposes a simple fix that makes this component more flexible in cases like these.)

Thanks for opening the issue on that extension's repo, @TurboProgramming !

@ardacebi
Copy link
Author

ardacebi commented Jul 2, 2018

@franzliedke No problem 👍
I want to help Flarum as much as I can!

We have only one problem, I submitted the bug report to the extension's repo but I haven't got any response in days, I'm still waiting but...

I'll tell here if I get any updates, this is important, because we'll also fix the bug on the community.

@tobyzerner
Copy link

Unless there is a problem with the search bar without extensions, then there is nothing for us to do.

Disagree - core has a responsibility to make room for extensions to do things easily without breaking or needing to change other parts of the interface. Any extension (including Links) should be able to add content to the header without needing to worry about the search component.

My view on this issue is rather that the current behaviour (the search bar overlapping other content when it expands) is the best compromise. It's completely usable, works with any amount of header content, and is technically easy to implement.

@ardacebi
Copy link
Author

ardacebi commented Jul 4, 2018

It's completely usable, works with any amount of header content, and is technically easy to implement.

@tobscure So should we open this issue again and search for a solution for the core instead of waiting for a solution for the extension?

@tobyzerner
Copy link

@TurboProgramming No - my view is that the current behaviour has the characteristics you quoted and we don't need to change it.

@ardacebi
Copy link
Author

ardacebi commented Jul 4, 2018

@tobscure Disagree on what you're saying - this looks really bad if you ask me, and I would like to see this changed.

Just want to learn one thing: if you had to fix this and make it look better, would you change the core, or the extension (if the extension was yours obviously)?

@ardacebi
Copy link
Author

ardacebi commented Jul 4, 2018

It's completely usable

@tobscure ...and just to make things clear, the thing you said by usability is true. I agree on that. Users are able to use it in any condition but by design and looks it looks bad.

None of the software out there does something like this...


On devices like iPad it looks way worse:

4567654576467

@franzliedke
Copy link

"Looking bad" is a very subjective term.

@tobscure Could we add a little drop shadow on the left side to make it clear that we're intentionally overlapping?

@tobyzerner
Copy link

@franzliedke sounds like a good solution, however the header is slightly transparent (and in custom themes, could have a background image or something) so that could be problematic :/

@luceos
Copy link
Member

luceos commented Jul 13, 2018

Personally I don't think this is an issue. We have no (full) control over the full size of that extensible menu bar to the left of the search. My vote would to keep as is.

@franzliedke
Copy link

Let's go with the drop shadow, though? It slightly improves the situation for the default theme without trying to deal with the length of dynamic content.

Other themes have to adopt the defaults anyway, so I don't see a problem in that regard...

@franzliedke franzliedke reopened this Jul 13, 2018
@pflstr
Copy link

pflstr commented Jul 17, 2018

I don't see a problem here either. Expanding elements when needed that then superimpose other elements is not a new concept, especially when dealing with the limited space of a mobile device.

If the expanded search bar wouldn't (potentially) have to overlap other elements, why would there be a reason to shrink it in the first place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants