Admin panel needs some mobile love

[ewinslow]

Assumes a desktop's amount of space. Very difficult to use.

[hypeJunction]

I think @PerJensen released a mobile friend admin panel to the community

[PerJensen]

Yes, Responsive admin panel, could easily be implementet.

[brettp]

Would we be able to merge this into the Aalborg theme?

[Srokap]

I'd like to keep admin panel separate from any theme.

[brettp]

I'd like to keep admin panel separate from any theme.

That was the plan for the admin area, but I think it'd be weird to default to a responsive admin area, but a non-responsive user area.

[Srokap]

I think the only good reason to have two themes instead of one is backward compatibility. I think we don't have this problem in admin panel. I wouldn't mind this weirdness for the sake of simplicity and ensuring admin panel stability.

Of course we might just bundle admin panel plugin, but that gives us 4 combinations of themes and even 2 default ones aren't 100% independent.

I just don't want to add complexity without good reason.

[ewinslow]

Agreed with Pawel. I don't think we should leave something broken solely
for consistency with something else that's broken.

Not super interested in investing a lot in the default theme anymore
either, personally. Aalborg is superior in every way. It should become the
new face of Elgg, IMO.

[brettp]

I suggested merging it into Aalborg for encapsulation of responsive designs with the idea of merging into core later. When we switch over to a responsive design in 1.10(?) it'd be just copying one theme into and one theme out of core.

[ewinslow]

Is there a reason to wait to go responsive? Why not just patch the default
theme and admin area during 1.9 to be better at this?

Evan Winslow
http://community.elgg.org/profile/ewinslow

On Sat, Apr 19, 2014 at 11:23 AM, Brett Profitt notifications@github.comwrote:

I suggested merging it into Aalborg for encapsulation of responsive
designs with the idea of merging into core later. When we switch over to a
responsive design in 1.10(?) it'd be just copying one theme into and one
theme out of core.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6742#issuecomment-40876749
.

[hypeJunction]

Do we need the default theme at all? Why not make Aalborg default, and
loose the current default?
On Apr 19, 2014 9:19 PM, "Evan Winslow" notifications@github.com wrote:

Is there a reason to wait to go responsive? Why not just patch the default
theme and admin area during 1.9 to be better at this?

Evan Winslow
http://community.elgg.org/profile/ewinslow

On Sat, Apr 19, 2014 at 11:23 AM, Brett Profitt notifications@github.comwrote:

I suggested merging it into Aalborg for encapsulation of responsive
designs with the idea of merging into core later. When we switch over to
a
responsive design in 1.10(?) it'd be just copying one theme into and one
theme out of core.

Reply to this email directly or view it on GitHub<
https://github.com/Elgg/Elgg/issues/6742#issuecomment-40876749>
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/6742#issuecomment-40878140
.

[brettp]

Because we eventually want to release 1.9. We have to have a feature cutoff
somewhere...

On Sat, Apr 19, 2014 at 3:45 PM, Ismayil Khayredinov <
notifications@github.com> wrote:

Do we need the default theme at all? Why not make Aalborg default, and
loose the current default?

On Apr 19, 2014 9:19 PM, "Evan Winslow" notifications@github.com wrote:

Is there a reason to wait to go responsive? Why not just patch the
default
theme and admin area during 1.9 to be better at this?

Evan Winslow
http://community.elgg.org/profile/ewinslow

On Sat, Apr 19, 2014 at 11:23 AM, Brett Profitt <
notifications@github.com>wrote:

I suggested merging it into Aalborg for encapsulation of responsive
designs with the idea of merging into core later. When we switch over
to
a
responsive design in 1.10(?) it'd be just copying one theme into and
one
theme out of core.

Reply to this email directly or view it on GitHub<
https://github.com/Elgg/Elgg/issues/6742#issuecomment-40876749>
.

Reply to this email directly or view it on GitHub<
https://github.com/Elgg/Elgg/issues/6742#issuecomment-40878140>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6742#issuecomment-40878758
.

Brett Profitt
Elgg Lead Developer

Elgg: http://elgg.org/
Skype: brett.profitt
Twitter: http://twitter.com/brettprofitt

[jdalsem]

Can we reboot this ticket, as there is code available for responsive admin area as mentioned before. I suggest to just fix it in core. If we are lucky it can go in 1.10 :)

[ewinslow]

Yes please

[PerJensen]

Yes, What is the conclusion here. Should we add Responsive admin panel mentioned above to core?

[juho-jaakkola]

No strong opinion. I wouldn't mind doing it.

[beck24]

Yes, responsive admin panel for 1.10

[ewinslow]

+1 yes please. Anything that would make this nicer.

On Sat, Oct 25, 2014, 10:13 AM Matt Beckett notifications@github.com
wrote:

Yes, responsive admin panel for 1.10

—
Reply to this email directly or view it on GitHub
#6742 (comment).

[PerJensen]

I have started working on this and it will include some style changes. Can this be accepted in a single commit or should it be split into several.

[jdalsem]

If they are all for this ticket it can be just one

[PerJensen]

When working on this, I've noticed that plugins (hypeThemeX) includes screenshots folder with images that appear when you click and open README.md (as far as I can see, the folder is not necessary though, since the images are displayed from external source).

This way of showing screenshots are not supported by existing CSS, therefore we must add something, not to break the layout.

Screenshots are usually added via manifest, which is supported by existing CSS (elgg-plugin-screenshot).

So the question is, should we support images in the readme:

.elgg-markdown img {
    max-width: 100%;
    height: auto;
    margin: 10px 0;
}

[jdalsem]

yes we should. Plugins also could use images like the scrutinizer or travis badges... those are no screenshots, but important in the readme

[hypeJunction]

I think any valid markdown should be supported.
As far as images are concerned, I have stopped using manifest screenshots entirely (#6778)