[DEV] [OFFICIAL] CODENAME: Chameleon

For style authors to post and receive feedback on 3.2.x styles still in development. Any development styles you wish to use on your live board should be installed with caution!
User avatar
mrgtb
Registered User
Posts: 557
Joined: Wed Oct 03, 2007 10:51 am

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by mrgtb » Sun Jun 09, 2019 5:25 pm

Looks nice and you even did a nice job with the new look of the editor changes to suit the theme.

Nothing to pick at really, I hope this becomes a reality and you get some help with doing it faster

User avatar
Flerex
Registered User
Posts: 87
Joined: Sun Oct 14, 2012 8:35 pm
Location: Galicia, Spain
Name: Flerex
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Flerex » Mon Jun 10, 2019 12:03 pm

Hanakin wrote:
Sun May 05, 2019 9:18 pm
just finished initial pass of an editor component take a look at the codepen: https://codepen.io/hanakin/pen/QPeoWd?editors=1100

It is still a work in progress...

The idea is to have one editor component that works for both full and quick modes. The editors will be fixed to the bottom with the page content scrollable behind it. so you enable the preview and it displays above and can scroll to see more of it without the editor window leaving your screen. Have not tested anything yet with that this is just an initial hack at it. So please hold the feedback until we get to an implementation phase... :D
Even though I have been following your work these last months and have always loved it, I have to come here to comment something that is bothering me about that concept you proposed. I know it's still a work in progress, but I have some concerns regarding one aspect of the UI that I think it was done on purpose.

I'm talking about the BBCode buttons. I don't understand the necessity of having all the BBCodes, which are a main formatting tool for posts, hidden under another menu. What before could be accomplished with one click (directly into the BBCode's button) now has to be done with two. That, I think, is a UI/UX design problem.

Similarly, some actions that I would assume have more hierarchical importance like “Save draft” or “Preview” are given the same importance as what I would also consider formatting actions (attachments and insert emoji).

I can see that you're getting your inspiration from GMail's compose mail popup but I don't think that's the best approach. In GMail, the format buttons are also hidden, but they stay opened once you click in the formatting menu. Even though that would fix the "two clicks for common actions" problem, it would also add an unnecessary click for something that I think is really used (especially on forums that create custom BBCodes). I understand GMail's approach: formatting is not that common when mailing, but I wouldn't say the same for forums.

Here are some examples of modern forums. As you can see, all of them have the formatting options always available:

Image
Image
Image
I would also like to note that in the previous image, in Flarum, they have acknowledged the fact that the preview has to be differentiated somehow from the rest of the formatting options by giving it a button treatment (with the grey background to note that is not primary).

I also would like to suggest to place the “Save Draft” button under a dropdown button. I mean, this action is not commonly used. By placing it in an alternative option from within the “Send” button we would provide a way to tell the user (UI-speaking) that both options (“Send” and “Save draft”) are mutually exclusive, related and also primary actions that would cause the page to refresh.

Image

Finally, the way you're designing the posting form is pretty complete. Can we not get rid of the “full mode” altogether? Right now the only things that I would assume are missing are the “Options” tab and (I think) the poll tab. Both could be added to this new interface and we wouldn't have the need to support the full mode at all, making it more modern and fresh.

User avatar
Hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 891
Joined: Wed Dec 30, 2009 8:14 am
Name: Michael Miday
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Hanakin » Mon Jun 10, 2019 4:56 pm

all component are built with a focus first for mobile. Also that component is for quick editor for now. As I am currently working on the topic page...When I work on a page I flush out all the components for that page. Once I get to the dedicated page for the editor we have more room to play with and if it makes sense on that page then sure we may change things but not sure yet until we get there. My current thought is to have it as a toggle on that page for large enough screens as a second row above the current one, but do not hold me to that.

Thanks for the suggestions Ill have a look at them as I get time.
Donations welcome via Paypal Image

User avatar
david63
Registered User
Posts: 16167
Joined: Thu Dec 19, 2002 8:08 am
Location: Lancashire, UK
Name: David Wood
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by david63 » Mon Jun 10, 2019 5:43 pm

Hanakin wrote:
Mon Jun 10, 2019 4:56 pm
all component are built with a focus first for mobile
Bear in mind that not everyone uses a mobile device.

Do you have any statistics on the use of mobile v non mobile devices for phpBB users to justify that assertion?
David
Remember: You only know what you know and - you don't know what you don't know!
My CDB Contributions | How to install an extension
I will not be accepting translations for any of my extensions in Github - please post any translations in the appropriate topic.
No support requests via PM or email as they will be ignored

User avatar
Hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 891
Joined: Wed Dec 30, 2009 8:14 am
Name: Michael Miday
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Hanakin » Mon Jun 10, 2019 5:50 pm

david63 wrote:
Mon Jun 10, 2019 5:43 pm
Hanakin wrote:
Mon Jun 10, 2019 4:56 pm
all component are built with a focus first for mobile
Bear in mind that not everyone uses a mobile device.

Do you have any statistics on the use of mobile v non mobile devices for phpBB users to justify that assertion?
What? All components are always and should be built mobile first it is a common practice. It allows for better thought process for handling responsive design as well as speeding up development and design along the process as you more quickly identify stratagies and common patterns
Donations welcome via Paypal Image

User avatar
Lumpy Burgertushie
Registered User
Posts: 66324
Joined: Mon May 02, 2005 3:11 am
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Lumpy Burgertushie » Mon Jun 10, 2019 6:23 pm

I understand that if you develop for mobile first and being repsonsive that it will most likely result in proper layout for desktops.

however, regardless of what the current stats are for mobile usage, there are still millions of us out here that use laptops and desktops and will continue to do so until they take my 32 inch monitor from my cold dead hands. :lol:

I think that to assume that hand held devices will be the only ones in the future is a little premature. hey, for all we know, everthing will change in the next five years and our computers/communications devices will be built into our brains and eyes etc.

hopefully I will be long gone before that all happens.

( tracking chips in your hand anybody? )


robert
I'm baaaaaccckkkk. still doing work on donation basis. PM your needs.

Premium phpBB 3.2 Styles by PlanetStyles.net

If a tree falls in the forest and nobody is there, does it make a sound?

User avatar
Crizzo
Translations & International Support Teams Manager
Translations & International Support Teams Manager
Posts: 884
Joined: Thu Apr 23, 2009 1:20 pm
Location: Germany
Name: Christian
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Crizzo » Mon Jun 10, 2019 7:14 pm

Mobile first is just a design approach.

There is only desktop first and adapt for mobile or mobile First. This does not mean, that there will be no desktop version.
My extensions for phpBB: crizzo.de
German phpBB Support at www.phpbb.de

User avatar
Hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 891
Joined: Wed Dec 30, 2009 8:14 am
Name: Michael Miday
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Hanakin » Mon Jun 10, 2019 10:13 pm

As crizzo said this has nothing to do with usage or stats! It just organizes design and dev to ensure we test all the devices
Donations welcome via Paypal Image

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 17003
Joined: Thu Jan 06, 2005 1:30 pm
Location: Fishkill, NY
Name: David Colón
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by DavidIQ » Tue Jun 11, 2019 3:39 pm

I'll just echo what has already been said: developing mobile first is an industry standard. If things are done/developed properly it should look fine on desktop as well with some possible adjustments.
Apply to become a Jr. Extension Validator
My extensions | In need of phpBB services? | Was I helpful today?
No unsolicited PMs unless you're planning on asking for paid help.

User avatar
Hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 891
Joined: Wed Dec 30, 2009 8:14 am
Name: Michael Miday
Contact:

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by Hanakin » Tue Jun 11, 2019 5:32 pm

Ok wanted to fully address the feedback now that I have properly had time to look over things.

First I have not iterated on this yet. This was just a quick through together. I still need to work order and priority but that requires some research and testing...currently I am reworking the project structure I have in place to make for an easier workflow for myself and anyone who wants to contribute.

Once I get that done i will continue working on this.

As such I also have not done any real testing and rework for the tablet/desktop versions. I usually do that upon migration from codepen to the project when I integrate it into a page. I am not there yet.

As for the extra click. On larger screens we have slightly more space and more actions could easily flow into the standard bar once priority order is worked out it should make for a better experience. When I get to this stage I will look into how to handle the secondary bar but I put this too you.

Most often people rarely use bbcodes for most posts. If they do its usually a select few and tend to be either the simple ones like bold/code or the custom ones like spoilers etc. Truthfully the standard ones such as size, italic, underline, list to be perfectly honest I would not rate very high compared to the others first of all I do not agree they should be strictly bbcodes. I would like to see them as markdown supported by default as well as this alleviates most of the need for them, not all but a good bit. I actually prefer to not stop typing to have to click a button and will usually end up typing the easier bbcodes by end any as its just faster.

I get that people are used to seeing these alot of places but that does not inherently mean it always makes for the most efficient or best UI/UX. I am not saying your point is wrong just that we want to iterate and test other alternatives as well to be sure.

Also as a note I tend to focus on my personal tastes during this initial mock-up stage as it speeds up the development/mock-up. Once we get to the integration and user testing stage we can really focus more on iterating and testing things like order and priority.
Flerex wrote:
Mon Jun 10, 2019 12:03 pm
I also would like to suggest to place the “Save Draft” button under a dropdown button. I mean, this action is not commonly used. By placing it in an alternative option from within the “Send” button we would provide a way to tell the user (UI-speaking) that both options (“Send” and “Save draft”) are mutually exclusive, related and also primary actions that would cause the page to refresh.
I have considered this since that is how google does it, but I do not have a component built for a split button yet to implement/test it.

Image
Flerex wrote:
Mon Jun 10, 2019 12:03 pm
Finally, the way you're designing the posting form is pretty complete. Can we not get rid of the “full mode” altogether? Right now the only things that I would assume are missing are the “Options” tab and (I think) the poll tab. Both could be added to this new interface and we wouldn't have the need to support the full mode at all, making it more modern and fresh.
seeing as how the most requested feature is by far a wysiwyg this may not happen but I am not against it.
Donations welcome via Paypal Image

User avatar
mrgtb
Registered User
Posts: 557
Joined: Wed Oct 03, 2007 10:51 am

Re: [DEV] [OFFICIAL] CODENAME: Chameleon

Post by mrgtb » Fri Jun 14, 2019 8:36 pm

DavidIQ wrote:
Tue Jun 11, 2019 3:39 pm
I'll just echo what has already been said: developing mobile first is an industry standard. If things are done/developed properly it should look fine on desktop as well with some possible adjustments.
Agree. Stats now on website visits tend to show more users are coming on mobile devices, than there is coming on desktop PCs.

Post Reply

Return to “[3.2.x] Styles in Development”