Re: [PatternFly] Browser support update

[Andres Galante]

I don't think there are pollyfills for css variables the way we are using
them or grids. But we can look into that.

On Tue, May 22, 2018 at 5:40 PM, Stan Silvert <ssilv...@redhat.com> wrote:

> On 5/22/2018 4:23 PM, Andres Galante wrote:
>
> Leslie has been meeting with different team to take this decisions based
> on their requirements and roadmaps. She is on vacation this week so we can
> probably continue this discussing next week.
>
> Here is my reasoning:
>
> IE11 is a burden, not only because we can't use css variables and grid
> among other modern CSS features but also because it increases the time of
> development to write fallbacks and testing and it makes the codebase harder
> to maintain.
>
> Patternfly next beta will out during the next 6 month-ish and a stable
> version probably by the end of the year or beginning of the next. By the
> time we have a stable version and projects start adopting it, it's a safe
> assumption that IE11 will be irrelevant.
>
> Does it make sense?
>
> I think your reasoning makes perfect sense.
>
> On the other hand, we can't just ignore 2% to 7% of our user base.  Even
> if IE11 is down to 1% of the market, we will still need a solution.   If 1
> out of 100 users can't use your web site then you are in trouble.
>
> If there is an effective pollyfill available then I think that would be
> good enough for us.
>
>
>
>
>
> On Tue, May 22, 2018 at 5:01 PM, Stan Silvert <ssilv...@redhat.com> wrote:
>
>> Maybe we can load a polyfill when we detect IE11?
>>
>> Would this work for all the new features you plan to use Andres?
>>
>>
>> On 5/22/2018 3:31 PM, Stian Thorgersen wrote:
>>
>> On keycloak.org we have ~5% on IE11 this year. Of IE users 95% of our
>> users are on IE11.
>>
>> Looking at https://www.w3counter.com/globalstats.php there's 2.81% for
>> IE11. On http://gs.statcounter.com/browser-market-share/desktop/worldwide
>> it says 7.17%, which I assume is mostly IE11. They don't give details on
>> individual versions as far as I can see.
>>
>> From my understanding there's still a lot of folks on Windows XP in the
>> world and a good proportion has not updated to Edge. I remember how long it
>> took to get rid of IE6.
>>
>> For RH-SSO and Keycloak we have login pages as well as the account
>> management console that both should be available to most users. Available
>> is subjective of course, but if there's CSS variables used which is not
>> supported at all on IE11 I would assume it would look very bad on IE11?
>>
>> On 22 May 2018 at 21:05, Andres Galante <agala...@redhat.com> wrote:
>>
>>> Hi Stian,
>>>
>>> How much of that IE traffic is IE11?
>>>
>>> On Tue, May 22, 2018 at 3:11 PM, Stian Thorgersen <sthor...@redhat.com>
>>> wrote:
>>>
>>>> According to http://gs.statcounter.com/browser-market-share/desktop/wo
>>>> rldwide
>>>>
>>>> IE11 is still more popular than Edge.
>>>>
>>>> I get the same numbers from keycloak.org.
>>>>
>>>> On 22 May 2018 at 20:07, Stian Thorgersen <sthor...@redhat.com> wrote:
>>>>
>>>>> Is the world really ready to move on from IE11? For admin facing apps
>>>>> I don't see it as a problem, but what about end-user facing apps?
>>>>>
>>>>> On 18 May 2018 at 10:53, Guillaume Vincent <gvinc...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> this is a good news, thank you patternfly !
>>>>>>
>>>>>> On Thu, May 17, 2018 at 1:22 PM, Andres Galante <agala...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Stan,
>>>>>>>
>>>>>>> Yes! it means we'll go back to use CSS variables following the same 2
>>>>>>> tier variable system
>>>>>>> <https://css-tricks.com/theming-with-variables-globals-and-locals/>
>>>>>>>
>>>>>>> We'll also be able to use CSS grids to build layouts :)
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 17, 2018 at 8:14 AM, Stan Silvert <ssilv...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm quite happy to ditch IE11.
>>>>>>>>
>>>>>>>> Does that mean PatternFly Next will use CSS variables instead of
>>>>>>>> preprocessor variables?  Eliminating the

Re: [PatternFly] Browser support update

[Andres Galante]

Leslie has been meeting with different team to take this decisions based on
their requirements and roadmaps. She is on vacation this week so we can
probably continue this discussing next week.

Here is my reasoning:

IE11 is a burden, not only because we can't use css variables and grid
among other modern CSS features but also because it increases the time of
development to write fallbacks and testing and it makes the codebase harder
to maintain.

Patternfly next beta will out during the next 6 month-ish and a stable
version probably by the end of the year or beginning of the next. By the
time we have a stable version and projects start adopting it, it's a safe
assumption that IE11 will be irrelevant.

Does it make sense?




On Tue, May 22, 2018 at 5:01 PM, Stan Silvert <ssilv...@redhat.com> wrote:

> Maybe we can load a polyfill when we detect IE11?
>
> Would this work for all the new features you plan to use Andres?
>
>
> On 5/22/2018 3:31 PM, Stian Thorgersen wrote:
>
> On keycloak.org we have ~5% on IE11 this year. Of IE users 95% of our
> users are on IE11.
>
> Looking at https://www.w3counter.com/globalstats.php there's 2.81% for
> IE11. On http://gs.statcounter.com/browser-market-share/desktop/worldwide
> it says 7.17%, which I assume is mostly IE11. They don't give details on
> individual versions as far as I can see.
>
> From my understanding there's still a lot of folks on Windows XP in the
> world and a good proportion has not updated to Edge. I remember how long it
> took to get rid of IE6.
>
> For RH-SSO and Keycloak we have login pages as well as the account
> management console that both should be available to most users. Available
> is subjective of course, but if there's CSS variables used which is not
> supported at all on IE11 I would assume it would look very bad on IE11?
>
> On 22 May 2018 at 21:05, Andres Galante <agala...@redhat.com> wrote:
>
>> Hi Stian,
>>
>> How much of that IE traffic is IE11?
>>
>> On Tue, May 22, 2018 at 3:11 PM, Stian Thorgersen <sthor...@redhat.com>
>> wrote:
>>
>>> According to http://gs.statcounter.com/browser-market-share/desktop/wo
>>> rldwide
>>>
>>> IE11 is still more popular than Edge.
>>>
>>> I get the same numbers from keycloak.org.
>>>
>>> On 22 May 2018 at 20:07, Stian Thorgersen <sthor...@redhat.com> wrote:
>>>
>>>> Is the world really ready to move on from IE11? For admin facing apps I
>>>> don't see it as a problem, but what about end-user facing apps?
>>>>
>>>> On 18 May 2018 at 10:53, Guillaume Vincent <gvinc...@redhat.com> wrote:
>>>>
>>>>> this is a good news, thank you patternfly !
>>>>>
>>>>> On Thu, May 17, 2018 at 1:22 PM, Andres Galante <agala...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Stan,
>>>>>>
>>>>>> Yes! it means we'll go back to use CSS variables following the same 2
>>>>>> tier variable system
>>>>>> <https://css-tricks.com/theming-with-variables-globals-and-locals/>
>>>>>>
>>>>>> We'll also be able to use CSS grids to build layouts :)
>>>>>>
>>>>>>
>>>>>> On Thu, May 17, 2018 at 8:14 AM, Stan Silvert <ssilv...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm quite happy to ditch IE11.
>>>>>>>
>>>>>>> Does that mean PatternFly Next will use CSS variables instead of
>>>>>>> preprocessor variables?  Eliminating the preprocessor will make me 
>>>>>>> double
>>>>>>> happy!
>>>>>>>
>>>>>>> For our app we want to allow an administrator to do simple theme
>>>>>>> changes from the admin console.  This gets really easy to implement if 
>>>>>>> the
>>>>>>> app doesn't need preprocessing.  If we have to use a preprocessor then 
>>>>>>> it
>>>>>>> becomes extremely complicated.
>>>>>>>
>>>>>>> Stan
>>>>>>>
>>>>>>>
>>>>>>> On 5/16/2018 4:55 PM, Leslie Hinson wrote:
>>>>>>>
>>>>>>> Hey Fliers
>>>>>>>
>>>>>>> At the last PatternFly Next update, the topic of IE11 browser
>>>>>>> support came up. Specifically, the question on whether or not we needed 
>>>>&

Re: [PatternFly] Browser support update

[Andres Galante]

Hi Stian,

How much of that IE traffic is IE11?

On Tue, May 22, 2018 at 3:11 PM, Stian Thorgersen <sthor...@redhat.com>
wrote:

> According to http://gs.statcounter.com/browser-market-share/desktop/
> worldwide
>
> IE11 is still more popular than Edge.
>
> I get the same numbers from keycloak.org.
>
> On 22 May 2018 at 20:07, Stian Thorgersen <sthor...@redhat.com> wrote:
>
>> Is the world really ready to move on from IE11? For admin facing apps I
>> don't see it as a problem, but what about end-user facing apps?
>>
>> On 18 May 2018 at 10:53, Guillaume Vincent <gvinc...@redhat.com> wrote:
>>
>>> this is a good news, thank you patternfly !
>>>
>>> On Thu, May 17, 2018 at 1:22 PM, Andres Galante <agala...@redhat.com>
>>> wrote:
>>>
>>>> Hi Stan,
>>>>
>>>> Yes! it means we'll go back to use CSS variables following the same 2
>>>> tier variable system
>>>> <https://css-tricks.com/theming-with-variables-globals-and-locals/>
>>>>
>>>> We'll also be able to use CSS grids to build layouts :)
>>>>
>>>>
>>>> On Thu, May 17, 2018 at 8:14 AM, Stan Silvert <ssilv...@redhat.com>
>>>> wrote:
>>>>
>>>>> I'm quite happy to ditch IE11.
>>>>>
>>>>> Does that mean PatternFly Next will use CSS variables instead of
>>>>> preprocessor variables?  Eliminating the preprocessor will make me double
>>>>> happy!
>>>>>
>>>>> For our app we want to allow an administrator to do simple theme
>>>>> changes from the admin console.  This gets really easy to implement if the
>>>>> app doesn't need preprocessing.  If we have to use a preprocessor then it
>>>>> becomes extremely complicated.
>>>>>
>>>>> Stan
>>>>>
>>>>>
>>>>> On 5/16/2018 4:55 PM, Leslie Hinson wrote:
>>>>>
>>>>> Hey Fliers
>>>>>
>>>>> At the last PatternFly Next update, the topic of IE11 browser support
>>>>> came up. Specifically, the question on whether or not we needed to support
>>>>> it moving forward.
>>>>>
>>>>> As a result, we wanted to follow up to ensure we understood PatternFly
>>>>> users' browser support roadmap. From what we've been able to gather, we
>>>>> learned that the majority of PatternFly users that are interested in
>>>>> migrating to PatternFly-Next are comfortable proceeding without IE11
>>>>> support moving forward. We will continue to have PF3 for any users that
>>>>> still require that level of support, however we don't believe that IE11
>>>>> support is worth the cost for this next major version.
>>>>>
>>>>> Thanks to everyone that raised this concern as well as those that
>>>>> provided input to help us make this decision.
>>>>>
>>>>> --
>>>>> Leslie Hinson
>>>>> PatternFly Lead, UXD
>>>>>
>>>>>
>>>>> ___
>>>>> PatternFly mailing 
>>>>> listPatternFly@redhat.comhttps://www.redhat.com/mailman/listinfo/patternfly
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> PatternFly mailing list
>>>>> PatternFly@redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>
>>>>>
>>>>
>>>> ___
>>>> PatternFly mailing list
>>>> PatternFly@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Guillaume  Vincent
>>>
>>> Senior FrontEnd Engineer
>>>
>>> gvinc...@redhat.com
>>> <https://red.ht/sig>
>>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>>
>>
>>
>
___
PatternFly mailing list
PatternFly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [PatternFly] Browser support update

[Andres Galante]

Hi Stan,

Yes! it means we'll go back to use CSS variables following the same 2 tier
variable system


We'll also be able to use CSS grids to build layouts :)


On Thu, May 17, 2018 at 8:14 AM, Stan Silvert  wrote:

> I'm quite happy to ditch IE11.
>
> Does that mean PatternFly Next will use CSS variables instead of
> preprocessor variables?  Eliminating the preprocessor will make me double
> happy!
>
> For our app we want to allow an administrator to do simple theme changes
> from the admin console.  This gets really easy to implement if the app
> doesn't need preprocessing.  If we have to use a preprocessor then it
> becomes extremely complicated.
>
> Stan
>
>
> On 5/16/2018 4:55 PM, Leslie Hinson wrote:
>
> Hey Fliers
>
> At the last PatternFly Next update, the topic of IE11 browser support came
> up. Specifically, the question on whether or not we needed to support it
> moving forward.
>
> As a result, we wanted to follow up to ensure we understood PatternFly
> users' browser support roadmap. From what we've been able to gather, we
> learned that the majority of PatternFly users that are interested in
> migrating to PatternFly-Next are comfortable proceeding without IE11
> support moving forward. We will continue to have PF3 for any users that
> still require that level of support, however we don't believe that IE11
> support is worth the cost for this next major version.
>
> Thanks to everyone that raised this concern as well as those that provided
> input to help us make this decision.
>
> --
> Leslie Hinson
> PatternFly Lead, UXD
>
>
> ___
> PatternFly mailing 
> listPatternFly@redhat.comhttps://www.redhat.com/mailman/listinfo/patternfly
>
>
>
> ___
> PatternFly mailing list
> PatternFly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
PatternFly mailing list
PatternFly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Patternfly for GSOC 2017

[Andres Galante]

Hi Jonathan,

We are participating under Fedora:

https://fedoraproject.org/wiki/Summer_coding_ideas_for_2017#Patternfly_Frontend_Pattern_Development




On Sun, Mar 5, 2017 at 1:34 PM, Jonathan Yu  wrote:

> Hi Gaurav,
>
> I'm not sure if PatternFly is participating in GSoC, and applications
> don't open until March 20 this year, however I suggest you join us on Slack
> and introduce yourself; head to http://slack.patternfly.org/ for an
> invite!
>
> Jonathan
>
> On Sun, Mar 5, 2017 at 4:18 AM,  wrote:
>
>> Hi Sir,
>> I'm Gaurav Sitlani, a young developer with intermediate Javascript and
>> python skills.
>> I have experience in front end development.
>> I'm interested in Open Source projects and becoming a contributor.
>> Worked on a project developing REST APIs. I want to work on this project
>> for Google Summer of Code this year.
>> Please Can you help me out with the same and become my mentor and guide
>> me in all aspects.
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] How to indicate Optional form fields?

[Andres Galante]

Hi Jonathan, I completely agree it seems silly to mark almost every line
with the *.

Using "optional" as a placeholder brings some undesired side effects. for
example, if a user wants to have a placeholder as a hint, then the optional
will have a conflicts. Also if the input is complete the placeholder would
disappear. Therefore we can't recommend using optional as a placeholder as
a universal solution for patternfly.

Maybe we should revisit this recommendation and try to find a better
solution for mostly mandatory fields.

Would you be able to work on it and propose a solution?

Thanks,

Andrés



On Wed, Mar 1, 2017 at 8:46 PM, Jonathan Yu  wrote:

> Hey PatternFlyers!
>
> We have a form that consists mostly of required fields, with a few
> optional fields.  It seems silly to mark all required fields with an
> asterisk (*) as it's 80%+ of the fields, but I can't figure out the correct
> style to get the behavior we want.
>
> I was using (Optional) to indicate these
> fields, but the PatternFly Forms guidance recommends against it:
>
> Required field: Required fields should be denoted with an * (asterisk)
>> symbol.
>> Due to responsiveness issues, we do not recommend labeling optional
>> fields with “(optional)”
>>
>
> See the Design tab of http://www.patternfly.org/pattern-library/forms-and-
> controls/forms/#/design (aside: why can't we link directly to the Design
> tab?)
>
> I came across a blog, which recommends using something that looks somewhat
> like a placeholder: https://blog.patternfly.org/required-fields/ - Design
> A1, which is labelled as the Recommended way to do things. Does anyone know
> what CSS class I need for this? (the little "optional" text in the inputs
> there)
>
>
>
> Currently we're using standard input placeholders, but I don't think this
> is the best use of them (they seem better used for syntax hints) - see the
> Middle Initial input:
>
>
> ​​
> "Greeting" is also optional but I'm not sure the best way to indicate that?
>
> --
> Jonathan Yu / Software Engineer, OpenShift by Red Hat / 140-character
> rants 'n raves 
>
> *“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”*
>  — Samuel Beckett
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Pure CSS Grid Systems?

[Andres Galante]

Hi Jonathan,

Bootstrap 5 has dropped support for ie9 on it's latest alpha (alpha 6) that
means that everything is based on flex. Overall the components are much
shallower, and modular and the grid system
 is much better. It also has
a set of very helpful utility classes and a special section for flex
utilities 

Putting together the new grid with the flex utilities allows us to create
more flexible and customizable structures for PF5.

Having said all that I am aware that Flex was not intended for grids and
CSS Grid is definitely a game changer. Even though we will have pretty good
support for CSS Grids later this year, browser support is not there yet.

So to answer your question, yes we will use flex grid for Patternfly 5, and
no we have no intentions to extend the grid using CSS grids.

Thanks for bringing this up, the future of CSS looks bright and exiting,
CSS Grids is happening sooner than later :)



On Wed, Mar 1, 2017 at 3:21 AM, Jonathan Yu  wrote:

> Lately, I've been seeing some really interesting examples of grid systems
> that leverage some modern browser layout capabilities, such as CSS Grid and
> Flexbox. Just wanted to share these & hear your thoughts:
>
> http://jensimmons.com/post/feb-28-2017/benefits-learning-
> how-code-layouts-css
>
> https://philipwalton.github.io/solved-by-flexbox/demos/grids/
>
> Will PatternFly 5 extend a framework like Bootstrap, or will it do away
> with that and use Flexbox directly? Or a framework that uses Flexbox
> underneath?
>
> Also, this little demo blew. my. mind. https://twitter.com/
> chriscoyier/status/836595681850707969
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] What would YOU like to see on the PatternFly Typography Page?

[Andres Galante]

I agree with Jonathan, we should remove all links to w3cschool and replace
them with MDN.

Material has a useful section about length of  paragraphs.

On Fri, Feb 24, 2017 at 3:43 PM, Jessica Ryhanych 
wrote:

> Hey Jenny,
> I agree with Matt here too – some kind of page or example that shows the
> typography styles in use on a page would be helpful. I know it wouldn't be
> a one size fits all solution but having real world examples would be nice
> to have to illustrate the system.
>
> Thanks!
> Jessica
>
> On Fri, Feb 24, 2017 at 1:40 PM Matt Carrano  wrote:
>
>> Hi Jenny,
>>
>> This might be what you mean when you say "Do's and Don'ts" regarding use
>> of type, but I've always felt we should have some guidelines about what
>> type styles to use for common elements like page titles, section headings,
>> sub headings, etc.
>>
>> Matt
>>
>> On Thu, Feb 23, 2017 at 5:41 PM, Greg Sheremeta 
>> wrote:
>>
>> [Way out of my domain of knowledge]
>> Should it say anything about color? What to do when there is a background
>> color?
>>
>> Best wishes,
>> Greg
>>
>>
>> On Thu, Feb 23, 2017 at 5:22 PM, Jenny Haines  wrote:
>>
>> Hi PatternFlyers-
>>
>> What additional information would you like to see on PatternFly's
>> Typography page? What would be useful to you? Our Current Typography Page
>> 
>>
>> Things I have seen included in UI Typography guides elsewhere:
>>
>>- "Do's and Don'ts" in regards to how to use type
>>- A table that includes the weight, point size, and tracking, and
>>usage for each text style
>>- Base and minimum font sizes
>>- Describing why the particular typeface was chosen, and why it works
>>for our applications
>>
>> Thank you!
>> *Jenny Haines*
>> *UI/VISUAL DESIGNER*
>> (m) 443-889-2881 <(443)%20889-2881>
>> jhai...@redhat.com
>> jennyhaine...@gmail.com
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Red Hat, Inc.
>> Sr. Software Engineer
>> gsher...@redhat.com
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>>
>>
>> --
>> Matt Carrano
>> Sr. Interaction Designer
>> Red Hat, Inc.
>> mcarr...@redhat.com
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
> --
> Jessica W. Ryhanych
> Interaction + Visual Designer, User Experience Design Team
> Red Hat
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Questions - can I search the mailing list archives?

[Andres Galante]

Hi Katherine,

You can search the mailing list archives here:
https://www.redhat.com/archives/patternfly/

You can preview the styles sheet, the code is open. Test pages for every
PatternFly component are here:
https://rawgit.com/patternfly/patternfly/master-dist/dist/tests/ and you
can see all the CSS (in this case LESS) for each component here:
https://github.com/patternfly/patternfly/tree/master/src/less

There is just one color scheme, but you can customize it by changing the
variables and compiling again:
https://github.com/patternfly/patternfly/blob/master/src/less/variables.less

Colors in PatternFly have enough contrast and are accessible for color
blind users, but we don't have all the aria tags, tab order or roles in
place for every component. That's something we are working to fix on the
next version of PatternFly.

Let me know if this helps and if you have any other question please contact
us here or on the slack channel: patternfly.slack.com

Thanks a lot,

Andrés



On Tue, Jan 3, 2017 at 9:34 AM, INSALL Katherine <
katherine.ins...@uk.thalesgroup.com> wrote:

> Hi,
>
> I just found PatternFly and am interested to learn more. Is there any way
> of searching the archived mailing list messages in case my questions have
> already been asked previously?
>
>
>
> My specific questions at the moment would be:
>
> -  Is there a way of previewing what the CSS styles look like
> without setting everything up?
>
> -  Is there more than one colour scheme already included?
>
> -  Do Patternfly components & styles follow any accessibility
> guidelines e.g. WAI standards? For example I’m looking at the example
> widgets on the website, thinking they look nice but wondering if they are
> accessible to colour blind users.
>
>
>
> My role is mainly UI / Interaction design rather than coding; I’m
> wondering if this library would be useful to save developers time and
> provide a consistent accessible base for applications.
>
>
>
> Kind regards,
>
> Kat Insall
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

[Patternfly] PatternFly Decision Tree

[Andres Galante]

Hello patternflyers,

During the past few weeks we've create a decision tree to help guide what
we should include in PatternFly and what not, as well as asses our current
components.

If you want to learn more about it, I've just publish a blog post on the
subject:

https://blog.patternfly.org/the-tree-of-wisdom/

Thanks!

Andrés
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

[Patternfly] November 21st Tech Talk

[Andres Galante]

Hello!

On Monday, November 21st, Patrick Riley and Andrés Galante invite you to a
journey through the process of architecting and developing PatternFly 4,
based on Bootstrap 4 and Web Components.

Please join us and discover our initial research building the next
generation of PatternFly: The challenge of upgrading to Bootstrap 4, how to
set up modular CSS based on Brad Frost’s Atomic Design principles and our
experience implementing behaviours via Web Components.

To join the Blue Jeans meeting: https://bluejeans.com/1919456002
To join via Browser: https://bluejeans.com/1919456002/browser
To join with Lync: https://bluejeans.com/1919456002/lync
To join via Room System: Video Conferencing System: bjn.vc -or-
199.48.152.152

I'll send a reminder closer to the date :)

Thanks!
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] [dev] patternfly templates for patternfly-org

[Andres Galante]

Thanks Gabriel for putting this guideline together.

If nobody has comments I think we should move this to the repo wiki.

On Thu, Nov 3, 2016 at 1:12 PM, Gabriel Cardoso  wrote:

> This email is for devs who contribute with code for the patternfly repo.
>
> Since I’ve been working in both repos, I created this document with good
> practices to write widgets in patternfly in a way that they can be consumed
> by patternfly-org to be displayed in the website.
>
> I ask you to please read it and give feedback. This is a round with devs
> inside Red Hat. The next step is to have it publicly in our repo.
>
> https://docs.google.com/a/redhat.com/document/d/1dtpJeUkHBCjxB_vw_zaQwZ_p-
> i0LpG54dslnrLpGbz8/edit?usp=sharing
>
> Many thanks,
> Gabriel
>
>
> Gabriel Cardoso
> UX designer @ Red Hat
>
>
>
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Truncation guidance for long names

[Andres Galante]

+1 go for the PR!

also to be clear I am not saying we should not truncating in the middle, I
just want to make us aware of the cost of it.

On Tue, Oct 25, 2016 at 2:28 PM, Liz Blanchard <lsure...@redhat.com> wrote:

> Thank you all for continuing to suggest directions and adding more
> examples of what's used out there for truncation.
>
> I think we all agree that truncation should be used only if needed, so I
> will be sure to add in a statement to encourage folks to try and show the
> full text when possible.
>
> It does sound like we have use cases for both truncation methods, but I
> will suggest that the first method should always be considered first.
> @Andres - maybe we can continue discussions around implementation details
> of method 2 in a PR? I hope to submit something to the design repo today.
>
> Thanks again, everyone!
>
> Liz
>
> On Tue, Oct 25, 2016 at 9:40 AM, Gabriel Cardoso <gcard...@redhat.com>
> wrote:
>
>> Andres, MacOS truncates in the middle ;)
>>
>>
>> On 24 Oct 2016, at 13:59, Catherine Robson <crob...@redhat.com> wrote:
>>
>> +1 to needing both end and middle based on the use case.
>>
>> On Mon, Oct 24, 2016 at 10:53 AM, Matt Carrano <mcarr...@redhat.com>
>> wrote:
>>
>>>
>>>
>>> The middle truncation is really useful for long path names that will all
>>> share the same prefix.  Think about things like files names or disk names
>>> that are required to display the full path name.  If out truncate the end,
>>> all of the name strings will be identical at a glance.  Middle truncation
>>> allows you to see what's different, which is usually at the end of the long
>>> string.
>>>
>>> I would expect that there are some standard algorithms out there for
>>> doing this.  End truncation is likely to be the default choice, but I think
>>> we need both.
>>>
>>> Matt
>>>
>>> On Mon, Oct 24, 2016 at 10:39 AM, Andres Galante <agala...@redhat.com>
>>> wrote:
>>>
>>>> Hi Liz,
>>>>
>>>> That's great information, this is the first time I heard about
>>>> truncation in the middle of the word.
>>>>
>>>> I am sure that middle of the string truncation can be done with
>>>> javascript, but CSS only allows to do it at the end of it. I'd say that
>>>> unless there is a really good reason to do it in the middle lets try to
>>>> avoid JS.
>>>>
>>>> Thanks!
>>>>
>>>> Andrés
>>>>
>>>>
>>>> On Mon, Oct 24, 2016 at 11:24 AM, Matt Carrano <mcarr...@redhat.com>
>>>> wrote:
>>>>
>>>>> This is great, Liz.  I think that your proposed text will add a lot of
>>>>> clarity to the choice between these two methods.  Will look forward to
>>>>> seeing some examples of truncated names and we can evaluate further.
>>>>>
>>>>> Matt
>>>>>
>>>>> On Mon, Oct 24, 2016 at 10:11 AM, Liz Blanchard <lsure...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I've been thinking about truncation a bit and was looking into some
>>>>>> UX standards on the topic. It's all very much in line with the examples
>>>>>> that Greg and Ju have given. What do you all think about extending the
>>>>>> PatternFly "Truncation" section on the Terminology and Wording page [1] 
>>>>>> to
>>>>>> include something like the following...
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *"Using an ellipsis to truncate a long string is recommended. There
>>>>>>> are two different methods that could be applied. One is to truncate at 
>>>>>>> the
>>>>>>> end of the string "abcdef..." and the other would be to truncate in the
>>>>>>> middle of the string "abc...ghi".Choose the method on the basis of 
>>>>>>> whether
>>>>>>> text at the end or in the middle of the string is more likely to
>>>>>>> differentiate the item. This would be dependent on the domain.On a 
>>>>>>> property
>>>>>>> website, for instance, an address string will usually end 'Road' or
>>>>>>> 'Street'. So the form 'abc...def' won't be much use as the f

Re: [Patternfly] Truncation guidance for long names

[Andres Galante]

I agree with Thomas, truncation should be a last resource and abbreviation
is preferable.

My comment on javascript vs CSS is about performance. I am not a js expert
but I expect that truncating a word in the middle would requiere measuring
spaces and adapting the string length to them.

It's absolutely doable but it should be avoided, a hit in performance, as
small as it can be results in worst user experience that means for example
less conversion.

If we have use cases that must use truncation in the middle and there is no
other solution for it, then we should move forward with this idea. But if
we should think of other options to accomodate long names in our UI without
doing middle of the string truncation.


On Tue, Oct 25, 2016 at 12:26 AM, Serena Doyle <sdo...@redhat.com> wrote:

> Matt, I also agree that we need both methods.  It would be great if we
> could provide guidance on when to use which method.
>
> I wonder if the method would also depend on naming conventions used by the
> customers.
>
> On Mon, Oct 24, 2016 at 11:59 AM, Catherine Robson <crob...@redhat.com>
> wrote:
>
>> +1 to needing both end and middle based on the use case.
>>
>> On Mon, Oct 24, 2016 at 10:53 AM, Matt Carrano <mcarr...@redhat.com>
>> wrote:
>>
>>>
>>>
>>> The middle truncation is really useful for long path names that will all
>>> share the same prefix.  Think about things like files names or disk names
>>> that are required to display the full path name.  If out truncate the end,
>>> all of the name strings will be identical at a glance.  Middle truncation
>>> allows you to see what's different, which is usually at the end of the long
>>> string.
>>>
>>> I would expect that there are some standard algorithms out there for
>>> doing this.  End truncation is likely to be the default choice, but I think
>>> we need both.
>>>
>>> Matt
>>>
>>> On Mon, Oct 24, 2016 at 10:39 AM, Andres Galante <agala...@redhat.com>
>>> wrote:
>>>
>>>> Hi Liz,
>>>>
>>>> That's great information, this is the first time I heard about
>>>> truncation in the middle of the word.
>>>>
>>>> I am sure that middle of the string truncation can be done with
>>>> javascript, but CSS only allows to do it at the end of it. I'd say that
>>>> unless there is a really good reason to do it in the middle lets try to
>>>> avoid JS.
>>>>
>>>> Thanks!
>>>>
>>>> Andrés
>>>>
>>>>
>>>> On Mon, Oct 24, 2016 at 11:24 AM, Matt Carrano <mcarr...@redhat.com>
>>>> wrote:
>>>>
>>>>> This is great, Liz.  I think that your proposed text will add a lot of
>>>>> clarity to the choice between these two methods.  Will look forward to
>>>>> seeing some examples of truncated names and we can evaluate further.
>>>>>
>>>>> Matt
>>>>>
>>>>> On Mon, Oct 24, 2016 at 10:11 AM, Liz Blanchard <lsure...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I've been thinking about truncation a bit and was looking into some
>>>>>> UX standards on the topic. It's all very much in line with the examples
>>>>>> that Greg and Ju have given. What do you all think about extending the
>>>>>> PatternFly "Truncation" section on the Terminology and Wording page [1] 
>>>>>> to
>>>>>> include something like the following...
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *"Using an ellipsis to truncate a long string is recommended. There
>>>>>>> are two different methods that could be applied. One is to truncate at 
>>>>>>> the
>>>>>>> end of the string "abcdef..." and the other would be to truncate in the
>>>>>>> middle of the string "abc...ghi".Choose the method on the basis of 
>>>>>>> whether
>>>>>>> text at the end or in the middle of the string is more likely to
>>>>>>> differentiate the item. This would be dependent on the domain.On a 
>>>>>>> property
>>>>>>> website, for instance, an address string will usually end 'Road' or
>>>>>>> 'Street'. So the form 'abc...def' won't be much use as the final 
>>>>>>

Re: [Patternfly] Truncation guidance for long names

[Andres Galante]

Hi Liz,

That's great information, this is the first time I heard about truncation
in the middle of the word.

I am sure that middle of the string truncation can be done with javascript,
but CSS only allows to do it at the end of it. I'd say that unless there is
a really good reason to do it in the middle lets try to avoid JS.

Thanks!

Andrés


On Mon, Oct 24, 2016 at 11:24 AM, Matt Carrano <mcarr...@redhat.com> wrote:

> This is great, Liz.  I think that your proposed text will add a lot of
> clarity to the choice between these two methods.  Will look forward to
> seeing some examples of truncated names and we can evaluate further.
>
> Matt
>
> On Mon, Oct 24, 2016 at 10:11 AM, Liz Blanchard <lsure...@redhat.com>
> wrote:
>
>> Hi All,
>>
>> I've been thinking about truncation a bit and was looking into some UX
>> standards on the topic. It's all very much in line with the examples that
>> Greg and Ju have given. What do you all think about extending the
>> PatternFly "Truncation" section on the Terminology and Wording page [1] to
>> include something like the following...
>>
>>
>>>
>>>
>>> *"Using an ellipsis to truncate a long string is recommended. There are
>>> two different methods that could be applied. One is to truncate at the end
>>> of the string "abcdef..." and the other would be to truncate in the middle
>>> of the string "abc...ghi".Choose the method on the basis of whether text at
>>> the end or in the middle of the string is more likely to differentiate the
>>> item. This would be dependent on the domain.On a property website, for
>>> instance, an address string will usually end 'Road' or 'Street'. So the
>>> form 'abc...def' won't be much use as the final characters will almost
>>> always be 'oad' or 'eet', neither of which help the user.If the answer is
>>> not clear, default to the 'abcdef...' form over 'abc...ghi'. Partial words
>>> will most likely be easier to guess from the initial characters than the
>>> end ones. 'Openi...' is much more recognizable than '...ening', for
>>> example."*
>>
>>
>> I'd also like to add in a statement where we suggest the use of the tool
>> tip on hover to view the entire string.
>>
>> I'm working on some specific use cases with the Storage product and we
>> definitely are seeing the need for both methods. More commonly, we will be
>> using method 1 for things like Cluster Name and Pool Name, but we are
>> considering method two for things like Hostname where the end characters
>> are important in differentiating the items in the list.
>>
>> Any further thoughts on this?
>>
>> Thanks!
>> Liz
>>
>> [1] http://www.patternfly.org/styles/terminology-and-wording/#_
>>
>> On Thu, Oct 20, 2016 at 8:12 PM, Andres Galante <agala...@redhat.com>
>> wrote:
>>
>>> Hi Matt, we definitely need guides around truncation, not only on server
>>> names but in general.
>>>
>>> It's always a grey area how and when to truncate.
>>>
>>> If working on Tendrl you can come up with some refomendations we can
>>> apply them to our patterns.
>>>
>>> Let me know if I can help in any way, we can test things up in different
>>> use cases to see if it works
>>>
>>> Thanks!
>>>
>>> On Monday, 10 October 2016, Ju Lim <ju...@redhat.com> wrote:
>>>
>>>> This generally works for most names except I've found in certain
>>>> contexts from previous experience that truncating in the front made more
>>>> sense, e.g. "...xyz" for MAC Addresses and SAN nicknames as it was less
>>>> useful doing it as "xyz..." since the beginning portion was repeated a lot
>>>> and didn't help so much with uniquely identifying the object.
>>>>
>>>> An interesting consideration is if there is a need for truncation of an
>>>> IPv6 addresses, how do we tackle this.  I know IPv6 already includes
>>>> truncation in the spec, but there are going to be circumstances where we
>>>> may need to go beyond this.  Thoughts?
>>>>
>>>> Regards,
>>>> Ju
>>>>
>>>> On Sat, Oct 8, 2016 at 11:59 AM, Greg Sheremeta <gsher...@redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Matt / all,
>>>>>
>>>>> This gets tricky when you have machine names in your listings!
>>>>> my_super_important_vm_1
>>>>> my_super_important_vm_2

Re: [Patternfly] PatternFly standard utility bar?

[Andres Galante]

I understand, there aren't docs about the Masthead design yet.

On example there Status and User links and the notification drawer has the
notification icon.

Matt, you are right, we need to standardized the order of those items and
decide what belongs and what doesn't belong in the Masthead.



On Fri, Oct 21, 2016 at 9:48 AM, Catherine Robson <crob...@redhat.com>
wrote:

> Andres,
>
> I think we are all trying to put these links in the masthead and that part
> is clear from the PatternFly examples and docs.  Matt's point below about
> options, ordering, etc. is what I think we're interested in seeing if we
> can standardize on.
>
> Looking at various examples, they look quite different (i.e. order of the
>> items, icons to use, whether user name is to be displayed or not).
>
>
> - Catherine
>
> On Thu, Oct 20, 2016 at 7:51 PM, Andres Galante <agala...@redhat.com>
> wrote:
>
>> Hi Matt, I believe that both the horizontal and vertical Nava have those
>> utility links on the masthead.
>>
>>
>>
>> On Thursday, 20 October 2016, Catherine Robson <crob...@redhat.com>
>> wrote:
>>
>>> I have a variety happening across projects as well Matt.  We generally
>>> show user as the right-most item, but then what happens is up for grabs
>>> project by project for the most part.  I think it also tends to vary based
>>> on height of the area where the username is placed.  We have a variety of
>>> headers in play in general, some shorter and some taller.
>>>
>>>
>>> On Thu, Oct 20, 2016 at 3:43 PM, Matt Carrano <mcarr...@redhat.com>
>>> wrote:
>>>
>>>> I am working on the Tendrl (Storage) console project and need to define
>>>> utility links for the right hand side of the masthead.  Specifically we
>>>> need links for About, Notifications, and User.
>>>>
>>>> Do we have a standard for this?   I know we did at one time , but I
>>>> can't find anything on the site.  Looking at various examples, they look
>>>> quite different (i.e. order of the items, icons to use, whether user name
>>>> is to be displayed or not).
>>>>
>>>> Welcome any examples of how you've handled this on your projects, also.
>>>>
>>>> Matt
>>>>
>>>>
>>>> --
>>>> Matt Carrano
>>>> Sr. Interaction Designer
>>>> Red Hat, Inc.
>>>> mcarr...@redhat.com
>>>>
>>>> ___
>>>> Patternfly mailing list
>>>> Patternfly@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>
>>>>
>>>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Truncation guidance for long names

[Andres Galante]

Hi Matt, we definitely need guides around truncation, not only on server
names but in general.

It's always a grey area how and when to truncate.

If working on Tendrl you can come up with some refomendations we can apply
them to our patterns.

Let me know if I can help in any way, we can test things up in different
use cases to see if it works

Thanks!

On Monday, 10 October 2016, Ju Lim  wrote:

> This generally works for most names except I've found in certain contexts
> from previous experience that truncating in the front made more sense, e.g.
> "...xyz" for MAC Addresses and SAN nicknames as it was less useful doing it
> as "xyz..." since the beginning portion was repeated a lot and didn't help
> so much with uniquely identifying the object.
>
> An interesting consideration is if there is a need for truncation of an
> IPv6 addresses, how do we tackle this.  I know IPv6 already includes
> truncation in the spec, but there are going to be circumstances where we
> may need to go beyond this.  Thoughts?
>
> Regards,
> Ju
>
> On Sat, Oct 8, 2016 at 11:59 AM, Greg Sheremeta  > wrote:
>
>> Hi Matt / all,
>>
>> This gets tricky when you have machine names in your listings!
>> my_super_important_vm_1
>> my_super_important_vm_2
>> his_super_important_vm_1
>>
>> ^ Either way you truncate that "column", someone's going to lose some
>> important info, and looking through the column will be frustrating for the
>> users.
>>
>> In oVirt, we take the simple approach and truncate at the end. And, in
>> most places where there is truncation, hovering over the truncated string
>> shows you (via tooltip) the entire string:
>>
>> [image: Inline image 1]
>>
>> My recommendation for PatternFly: recommend / default to end truncation
>> with "...". I like the hover-show-full-name feature -- that's something UX
>> people should discuss re: if it should exist and what it would look like.
>> (We use PF tooltips, but I could see other widgets being useful.)
>>
>> Best wishes,
>> Greg
>>
>> On Fri, Oct 7, 2016 at 2:08 PM, Matt Carrano > > wrote:
>>
>>> Hey Patternflyers,
>>>
>>> I am currently working on the Tendrl storage console project and need to
>>> come up with some guidance on how to truncate long names that may appear in
>>> our UI.  I'm thinking of things like hostnames, disk names, and other types
>>> of objects that may take on a potentially long path name based on user
>>> naming.  PatternFly currently provides some general guidance, but no
>>> specific rules.
>>>
>>> I'm curious how you are handling this on other projects as I know it's a
>>> common problem.  Do you truncate in the middle of the string, the end of
>>> the string, or have another method?
>>>
>>> Any advice or examples will be welcome.
>>>
>>> Regards,
>>>
>>> Matt
>>>
>>> --
>>> Matt Carrano
>>> Sr. Interaction Designer
>>> Red Hat, Inc.
>>> mcarr...@redhat.com
>>> 
>>>
>>> ___
>>> Patternfly mailing list
>>> Patternfly@redhat.com
>>> 
>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>
>>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Red Hat, Inc.
>> Sr. Software Engineer
>> gsher...@redhat.com 
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> 
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
>
> --
> Ju Lim
> Red Hat
> Office: 978-399-0422
> Mobile: 781-507-1323
> Email: ju...@redhat.com 
> IRC: julim
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Web Component Rendering Performance

[Andres Galante]

Patrick you are awesome 

Great article and even better Q

On Tuesday, 11 October 2016, Patrick Riley <pri...@redhat.com> wrote:

> Hello Patternfliers,
>
> I wanted to share my recent post on web component rendering analysis. A
> huge thanks to Brian Leathem, Andres Galante, and Dana Gutride for helping
> review this with me and raising different challenges along the way.
>
> https://medium.com/@priley86/building-cross-framework-
> components-with-performance-in-mind-a-web-component-
> thesis-5e17353aee18#.hpg56in0w
>
> The key examples in this post are here:
> https://plnkr.co/edit/dDf25hgHIkqqPzvdlJl9?p=preview
> https://plnkr.co/edit/Ds77ZqlxJIV87TSXOZuV?p=preview
> http://www.webpackbin.com/N1fwEMX0Z
> http://www.webpackbin.com/Ey_W-1I0Z
>
>
> I want to ask the community now for feedback and see what our other
> developers at Red Hat think about this. I've received a few early questions
> about this and I'd like to address them here first. Please feel free to add
> on to this discussion if you disagree!
>
> *Question*:
> *"i'd like to see a discussion of loading/TTI on phones"*
> https://twitter.com/slightlylate/status/785192470082560001
>
> *Response*: TTI and the "critical rendering path" are still of utmost
> important for making your app fast and giving a fast first impression. I
> think web components still fit the bill if the same care is taken to ensure
> they are lightweight and rendered properly. When used as leaf nodes/jquery
> plugin replacements alongside fast rendering frameworks like
> virtual-dom/incremental-dom, they make your app very responsive
> *throughout* the experience too. If TTI is your only goal, I'd recommend
> looking at the "isomorpic" javascript/server rendering approach (this is
> becoming common now in the React ecosystem). "Server" components should
> help here too..
>
> Relevant links:
> https://pimterry.github.io/server-components/
> https://developers.google.com/web/fundamentals/performance/
> critical-rendering-path/
> https://github.com/kriasoft/universal-router
> http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
>
> *Question*:
> Can I pass arrays/objects to web components the same way I do angular
> directives or React components?
>
> *Response*:
> Ironically, web component "DOM" behaves the same way as other DOM. There
> is currently nothing in the browser spec which allows anything but strings
> in your DOM attributes. Rob Dodson mentions this as a current "platform"
> limitation. However, React and Angular provide "sugar" which enables you to
> pass arrays/objects to nested components. We can do the same thing with web
> components by selecting the DOM element with JS and setting properties or
> "instantiating" them as classes and setting them on initialization. Example
> of this with Skate JS here:
> https://jsfiddle.net/patrickriley/hsoup9pj/12/
>
> There is also a great discussion about this in a recent podcast on
> Javascript Air here:
> https://javascriptair.com/episodes/2016-09-28/
>
> There's also been some discussion on how to make your web components
> behave more like React here:
> https://component.kitchen/blog/posts/using-react-app-
> techniques-at-the-web-component-level-with-redux-virtual-dom-and-jsx
>
>
> Hope you enjoy the reading and dive in to this discussion :)
>
> -Patrick
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] PatternFly standard utility bar?

[Andres Galante]

Hi Matt, I believe that both the horizontal and vertical Nava have those
utility links on the masthead.



On Thursday, 20 October 2016, Catherine Robson  wrote:

> I have a variety happening across projects as well Matt.  We generally
> show user as the right-most item, but then what happens is up for grabs
> project by project for the most part.  I think it also tends to vary based
> on height of the area where the username is placed.  We have a variety of
> headers in play in general, some shorter and some taller.
>
>
> On Thu, Oct 20, 2016 at 3:43 PM, Matt Carrano  > wrote:
>
>> I am working on the Tendrl (Storage) console project and need to define
>> utility links for the right hand side of the masthead.  Specifically we
>> need links for About, Notifications, and User.
>>
>> Do we have a standard for this?   I know we did at one time , but I can't
>> find anything on the site.  Looking at various examples, they look quite
>> different (i.e. order of the items, icons to use, whether user name is to
>> be displayed or not).
>>
>> Welcome any examples of how you've handled this on your projects, also.
>>
>> Matt
>>
>>
>> --
>> Matt Carrano
>> Sr. Interaction Designer
>> Red Hat, Inc.
>> mcarr...@redhat.com 
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> 
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Move to Slack

[Andres Galante]

Hi,

The slack channel started last week and it has been active.

If you can't join, please send me your email address and I'll send an
invitation.

Thanks!


On Wed, Oct 12, 2016 at 8:31 AM, Andres Galante <agala...@redhat.com> wrote:

> Ok, let's give this a try :)
>
> I've started a PatternFly slack team here: patternfly.slack.com
>
> Please join and lets see what happens
>
> Also, I've found this bot to log slack: https://github.com/
> AhmadMelegy/Slack-logger-bot
>
> Anyone interested in testing it out?
>
> Thanks a lot!
>
>
>
> On Tue, Oct 4, 2016 at 2:45 PM, Andres Galante <agala...@redhat.com>
> wrote:
>
>> Thanks Patrick,
>>
>> That's a good point, Gitter is a good tool. It's not about the tool,
>> it's about brining the communication channel to the place where the
>> discussion is happening.
>>
>> It's about been more open.
>>
>> The logs might be a concern, but we don't keep logs on our IRC channel
>> anyway :p
>>
>>
>>
>>
>> On Mon, Oct 3, 2016 at 11:41 AM, Patrick Riley <pri...@redhat.com> wrote:
>>
>>> I'd be OK with moving to Slack and Gitter or solely to Gitter. Gitter
>>> channels can be used independently from Github repos now, do not have the
>>> chat limit history issue, and allow you to create teams now (a huge thanks
>>> to David Halasz for mentioning this). It also helps you frame discussions
>>> more around Github repos/issues when desired (so that's a huge perk for
>>> developers). It looks Gitter supports the same level of "fun" with Giphy
>>> integrations too. There is mobile apps for Gitter too.
>>>
>>> https://github.com/dervondenbergen/giphy-gitter
>>> https://gitter.im/apps
>>>
>>> I have a really hard time tracking IRC, Gitter, Slack, Rocket Chat among
>>> others, and would love to standardize and use less tools to save valuable
>>> CPU cycles.
>>>
>>> My $.02.
>>>
>>> *-Patrick*
>>>
>>>
>>>
>>> ___
>>> Patternfly mailing list
>>> Patternfly@redhat.com
>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>
>>>
>>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Move to Slack

[Andres Galante]

Thanks Patrick,

That's a good point, Gitter is a good tool. It's not about the tool, it's
about brining the communication channel to the place where the discussion
is happening.

It's about been more open.

The logs might be a concern, but we don't keep logs on our IRC channel
anyway :p




On Mon, Oct 3, 2016 at 11:41 AM, Patrick Riley  wrote:

> I'd be OK with moving to Slack and Gitter or solely to Gitter. Gitter
> channels can be used independently from Github repos now, do not have the
> chat limit history issue, and allow you to create teams now (a huge thanks
> to David Halasz for mentioning this). It also helps you frame discussions
> more around Github repos/issues when desired (so that's a huge perk for
> developers). It looks Gitter supports the same level of "fun" with Giphy
> integrations too. There is mobile apps for Gitter too.
>
> https://github.com/dervondenbergen/giphy-gitter
> https://gitter.im/apps
>
> I have a really hard time tracking IRC, Gitter, Slack, Rocket Chat among
> others, and would love to standardize and use less tools to save valuable
> CPU cycles.
>
> My $.02.
>
> *-Patrick*
>
>
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Move to Slack

[Andres Galante]

Hi Alex,

PatternFly is a unique community that joins developers and designers.

Designers do not use IRC. Since I love IRC and I believe in the power of
freenode, I did try to push them there. The ones that finally land on IRC
just ignore the channel.

Slack is less scary than IRC :) and many designers are already there. The
core team of designers building PatternFly is on Slack.

I want to bring the communication channel to where the core committers are,
instead of pushing the core committers to use a new tool.

I would like to include the rest of the community to the discussions the
UXD team is already having on Slack, and the only way I can think of doing
that is by moving our communication channel.

if the mountain won't come to Muhammad...

Maybe I am wrong, I know this move is controversial. It's not about Slack
itself, it's about been more open.

I'd like to know if there are other options to solve this problem.

Thank,

Andrés


On Fri, Sep 30, 2016 at 10:59 AM, Alexandre Porcelli Bakos <
porce...@redhat.com> wrote:

> Andres,
>
>  What makes you think that by using Slack instead of an IRC channel
> (that, as you mentioned) is usually crowded would improve the
> discussions?
>  I've been on OSS for a while now, I've been part of so many vibrant
> communities... and all in common using the good old IRC.
>
> Regards,
> ---
> Alexandre Porcelli
> Principal Software Engineer
> Red Hat Business Systems and Intelligence Group
>
>
> On Fri, Sep 30, 2016 at 7:27 AM, Andreas Nilsson <anils...@redhat.com>
> wrote:
> > On 2016-09-29 22:17, Andres Galante wrote:
> >>
> >> Hi!
> >>
> >> I want us to move the PatternFly community chat to Slack.
> >>
> >> I feel that even though the IRC channel is usually crowded there is not
> >> enough discussion.
> >>
> >> I love IRC but since the UXD team is on Slack, all of our designers and
> >> most of our developers are on Slack.
> >
> >
> > It would be one more app for me to install and keep open, but if it
> allows
> > for one less client for the rest of you to have open, I'm happy to carry
> the
> > burden. :)
> >
> > PS. This is more of an internal company thing, but I'm happy to join the
> UXD
> > slack channel too, because I'm a bit isolated out here in my department.
> > Totally up for taking that discussion off-list.
> >
> > - Andreas
> >
> >
> > ___
> > Patternfly mailing list
> > Patternfly@redhat.com
> > https://www.redhat.com/mailman/listinfo/patternfly
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Move to Slack

[Andres Galante]

Yes, that's the down side. You can only do logs on slack with a paid
account.

I'll look into it, maybe they have a plan for oss projects.

On Friday, 30 September 2016, Sarah Rambacher <sramb...@redhat.com> wrote:

> +1, at the CSS Conf this week, everyone seemed to be using Slack.
> One thought - our team channels lose history after a while because of a
> message limit. Will we be up against the same limit?
>
> On Thu, Sep 29, 2016 at 7:37 PM, Serena Doyle <sdo...@redhat.com
> <javascript:_e(%7B%7D,'cvml','sdo...@redhat.com');>> wrote:
>
>> Ah, yes I meant teams.  Thanks Tiffany for sending along the info!
>>
>>
>> On Thursday, September 29, 2016, Tiffany Nolan <tno...@redhat.com
>> <javascript:_e(%7B%7D,'cvml','tno...@redhat.com');>> wrote:
>>
>>> I think Serena is asking about being able to sign in and navigate
>>> between different Slack teams. It's pretty easy to setup and you can
>>> quickly jump between all your teams from the UI. Here's some more info:
>>> https://get.slack.help/hc/en-us/articles/201405046-Sig
>>> n-in-to-multiple-Slack-teams
>>>
>>> Kind regards,
>>>
>>> *Tiffany Nolan*
>>> Senior Interaction Designer - Developer Experience
>>> UXD Team | Red Hat Westford
>>> tno...@redhat.com
>>>
>>>
>>> *Good design, when it’s done well, becomes invisible. It’s only when
>>> it’s done poorly that we notice it.**– Jared Spool*
>>>
>>> On Thu, Sep 29, 2016 at 5:46 PM, Andres Galante <agala...@redhat.com>
>>> wrote:
>>>
>>>> Yes, there are people in gitter also.
>>>>
>>>> I'd like to consolidate everything in slack.
>>>>
>>>> It would be a new separate team, not a new channel. I don't understand
>>>> your question, what do you mean by integrate multiple channels?
>>>>
>>>> Bootstrap move to slack is a huge success, brining more designers to
>>>> the discussions and creating a more friendly community than the hardcore
>>>> IRC one.
>>>>
>>>> Thanks,
>>>>
>>>> Andres
>>>>
>>>>
>>>> On Thursday, 29 September 2016, Serena Doyle <sdo...@redhat.com> wrote:
>>>>
>>>>> Andres,  Aren't a lot of people using gitter as well?
>>>>>
>>>>> Per slack, if that's done, I'm assuming that would be another Slack
>>>>> channel.  How easy/hard is the integration of multiple slack channels?
>>>>>
>>>>> Thanks,
>>>>> - Serena
>>>>>
>>>>> On Thu, Sep 29, 2016 at 4:17 PM, Andres Galante <agala...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I want us to move the PatternFly community chat to Slack.
>>>>>>
>>>>>> I feel that even though the IRC channel is usually crowded there is
>>>>>> not enough discussion.
>>>>>>
>>>>>> I love IRC but since the UXD team is on Slack, all of our designers
>>>>>> and most of our developers are on Slack.
>>>>>>
>>>>>> By doing that move we would be taking discussion where people are
>>>>>> enabling more transparent and active discussions.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> ___
>>>>>> Patternfly mailing list
>>>>>> Patternfly@redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> - Serena Chechile Doyle
>>>>> *UXD | Unified Management Experience*
>>>>> *Red Hat*
>>>>> *Cell* 508-769-7715 | *IRC* - serena | *Skype* - serenamarie125 |
>>>>> *Twitter* - @serenamarie125
>>>>>
>>>>
>>>> ___
>>>> Patternfly mailing list
>>>> Patternfly@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>
>>>>
>>>
>>
>> --
>> - Serena Chechile Doyle
>> *UXD | Unified Management Experience*
>> *Red Hat*
>> *Cell* 508-769-7715 | *IRC* - serena | *Skype* - serenamarie125 |
>> *Twitter* - @serenamarie125
>>
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> <javascript:_e(%7B%7D,'cvml','Patternfly@redhat.com');>
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

[Patternfly] Move to Slack

[Andres Galante]

Hi!

I want us to move the PatternFly community chat to Slack.

I feel that even though the IRC channel is usually crowded there is not
enough discussion.

I love IRC but since the UXD team is on Slack, all of our designers and
most of our developers are on Slack.

By doing that move we would be taking discussion where people are enabling
more transparent and active discussions.

What do you think?
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Request to include flexbox

[Andres Galante]

You are right, PatternFly is based on bootstrap 3.

On Tue, Sep 27, 2016 at 5:32 AM, Soumya Deb <d...@redhat.com> wrote:

> Thanks for the info, Andreas.
>
> Please correct me if I'm wrong, but that implies BS4 based PF to not be a
> consumable product for Tendrl/RHSC (development ongoing).
>
>
> On 26 September 2016 at 21:29, Andres Galante <agala...@redhat.com> wrote:
>
>> Hi Soumya,
>>
>> Patternfly relies on Bootstrap grid system, which is based on floats.
>>
>> Until we move to bootstrap 4 we will not have a flexbox grid. I'll
>> probably have more info about when and how this upgrade is going to happen
>> in the next few days.
>>
>> Thanks
>>
>>
>> On Fri, Sep 23, 2016 at 7:08 AM, Soumya Deb <d...@redhat.com> wrote:
>>
>>> FWIW, as a clarification, the Tendrl frontend team wanted to avoid
>>> floating grids, and use flexbox based layouts.
>>> It has nothing to do with the spec-non-solidified grid layout - that's
>>> out of the picture.
>>>
>>> Our app is mostly targeted for modern browsers, although a clear
>>> boundary hasn't been drawn yet (as Ju mentioned).
>>>
>>> We do want to use patternfly for all the features it brings, but not
>>> having flexbox layouts are only concern against it.
>>>
>>>
>>> On 22 September 2016 at 21:00, Ju Lim <ju...@redhat.com> wrote:
>>>
>>>> Thanks Andres for getting back to the Tendrl UI Dev team (CCed).  The
>>>> Tendrl team is still exploring different options, so your feedback is
>>>> timely.
>>>>
>>>> Serena -- We don't know yet which browsers we'll support yet as the
>>>> Tendrl Support Matrix is still being decided.  We'll let you know once it
>>>> gets known.
>>>>
>>>> Thanks again,
>>>> Ju
>>>>
>>>> On Thu, Sep 22, 2016 at 8:15 AM, Andres Galante <agala...@redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Ju,
>>>>>
>>>>> I am sure the Tendrl is confused.
>>>>>
>>>>> Flexbox is a CSS property that provides the ability to  arrange
>>>>> elements in the page. [1]
>>>>>
>>>>> Grid layout, is a new spec, still a draft on the W3C and with almost
>>>>> no adoption on browsers. [2]
>>>>>
>>>>> Semantic UI framework uses flexbox to build their grid system. Since
>>>>> boostrap 3 was born before flexbox, then its grid its based on floats.
>>>>>
>>>>> Bootstrap 4 has an option to use flexbox and we will use it when we
>>>>> migrate to 4 on the next steps of patternfly. As for when, I don't know,
>>>>> but I'll have more info after this week.
>>>>>
>>>>> Its important to notice that BS4 is an alpha so anything can change.
>>>>>
>>>>> Can they use flexfox now? the answer of source its "it depends".
>>>>> Flexbox support is pretty good at the moment but if they want to support
>>>>> older browser the wont be able to use it [3]
>>>>>
>>>>> My recommendation is for them to use bootstrap grid system, its works
>>>>> good with floats and when patternfly moves to Bootstrap 4 the migration of
>>>>> the grid would be almost transparent.
>>>>>
>>>>> That is a good question though, we are living a huge change on layouts
>>>>> with flexbox and CSS grid layout, exiting times for CSS and the web!
>>>>>
>>>>> [1] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexibl
>>>>> e_Box_Layout/Using_CSS_flexible_boxes
>>>>> [2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout
>>>>> [3] http://caniuse.com/#feat=flexbox
>>>>>
>>>>>
>>>>> On Wed, Sep 21, 2016 at 3:46 PM, Serena Doyle <sdo...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Ju,
>>>>>>
>>>>>> Do you know what browsers RH Storage will be supporting ?
>>>>>>
>>>>>> Thanks,
>>>>>> - Serena
>>>>>>
>>>>>> On Wed, Sep 21, 2016 at 2:18 PM, Ju Lim <ju...@redhat.com> wrote:
>>>>>>
>>>>>>> PF Team:
>>>>>>>
>>>>>>> The Tendrl (downstream product name is Red Hat Storage Console)
>>>>

[Patternfly] Change PatternFly release day

[Andres Galante]

Hi,

We are doing a small change in our release dates.

Until now it has been every other Tuesday, the same day our sprints
end. This is causing conflicts with code arriving on the same day we do
releases.

That’s why the repos will be frozen on Tuesdays EOB and we are moving
releases to Wednesday.

Thanks,

Andrés
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Updated Balsamiq Mockups template for PatternFly is available

[Andres Galante]

I've just loaded the templates on Balsamiq.

It's really cool, very useful for fast wireframing.

Thanks Matt!

On Tue, Jul 26, 2016 at 10:41 AM, Matt Carrano  wrote:

> I have created an updated version of the PatternFly template for Balsamiq
> Mockups.  This is useful for anyone using Mockups to create wireframes that
> will later be implemented in PatternFly.  The templates and instructions
> about how to use can be found in a shared folder here:
>
> https://drive.google.com/open?id=0BzFElDXgLrtdTnh1YU5Mc1IzTjQ
>
> The following is a summary of the changes and additions that you can find
> in the new version.
>
> - Switch widget
> - Touchspin Widget
> - Aggregate Status Cards
> - List View pattern and layouts
> - Vertical Navigation layouts
> - Toast Notifications and updated Inline Alert styling
> - Additional PatternFly custom icons
>
> Let me know if you have any questions or run into any problems using the
> template.
>
> Regards,
> --
> Matt Carrano
> Sr. Interaction Designer
> Red Hat, Inc.
> mcarr...@redhat.com
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Consolidating patternfly dependency management

[Andres Galante]

+1
I agree that we should consolidate npm for our development env build.


On Thu, Jul 28, 2016 at 12:26 PM, Patrick Riley  wrote:

> I tend to agree that solidifying our dependency base with *npm* is a good
> move for the long term in Patternfly. It appears the Angular and React team
> have moved solely to *npm* for managing dependencies as well. This can
> only speak to the fact that *npm* is much more actively maintained and
> has become a standard for managing front-end as well as back-end javascript
> dependencies.
>
> I found a good reference here with discussion around moving towards npm.
> It offers some good suggestions and common challenges.
> https://gofore.com/stop-using-bower/
>
> I would also agree that maintaining our Patternfly bower package for the
> community would be desired until we determine otherwise.
>
> Any other ideas about this from the group?
>
> *Patrick Riley*
> Interaction Designer - Software Engineer, RedHat, Inc.
> 100 E Davie St, Raleigh, NC 27601
>
> pri...@redhat.com | office: 919-890-8331 | mobile: 859-536-6767
>
>
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Designers needed for patternfly design repo trial

[Andres Galante]

Wow, I wasn't expecting some many volunteers!

We will run some test in a smaller scale and finish the details these days
and I'll set a meeting for later this week or early next week.

Thanks a lot!

Andrés

On Mon, Jul 11, 2016 at 6:20 AM, Andreas Nilsson <anils...@redhat.com>
wrote:

> On 2016-07-07 19:38, Andres Galante wrote:
>
>> Hi,
>>
>> We want to user test a new way for designers to contribute to patternfly
>> with a github flow.
>>
>> After many discussion we came down to a process to submit designs specs
>> though Githubs UI that we think it'll be easy to adopt and will streamline
>> the design contributions.
>>
>> To test and troubleshoot it we need designers!
>>
>
> I have a need to contribute back things from Cockpit to Patternfly from
> time to time, so I'm happy to help testing.
> - Andreas
>
>
> ___
> Patternfly mailing list
> Patternfly@redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Patternfly design submission inquiry

[Andres Galante]

(I am ccing the PatternFly Mailing list.)

Awesome Ebonee!

Your timing couldn't be better to contribute a design spec. We are working
on better contributing guidelines and a path for designers to became part
of the community and submit designs.

We'll probably have news about it soon and the community needs members like
you to help discuss and trouble shoot and improve them.

The ida is that designers can participate on the community just as
developers through github. A design spec will have a physical
representation on the repository and will be a living document where other
members of the community can improve or comment on it.

So, I encourage you to write the spec on markdown
<https://guides.github.com/features/mastering-markdown/>, since that will
be the format it will have on github.

If you have questions about markdown or anything else, or you want to chat
about your ideas please join the IRC channel #patternfly @freenode.

Thanks


On Thu, Jun 9, 2016 at 11:43 AM, Ebonee Farrow <etfar...@gmail.com> wrote:

> Hi Andres,
>
> You're not asking too many questions at all!  I'm glad you like the idea.
> I agree, animated bubble charts are definitely interesting.  At the moment,
> I'm interested in contributing design specs.  I am still working on
> documentation and a use case that needs bubble charts and will continue to
> work on my proposal for the design spec by first designing and defining the
> pattern.
>
> I'm excited about the opportunity and look forward to working with you and
> the rest of the Patternfly community.  Please let me know if you have any
> more questions or more information you'd like to share with me.
>
> Thanks Again,
> Ebonee
>
> On Thu, Jun 9, 2016 at 7:07 AM, Andres Galante <agala...@redhat.com>
> wrote:
>
>> Hi Ebonee,
>>
>> I like your idea. Bubble charts can be interesting and beautiful,
>> specially when they are animated d3 style.
>>
>> Are you working on a usecase that needs bubble charts?
>>
>> Do you want to contribute code or a design spec?
>>
>> If it's code, PatternFly uses c3 to drive data visualization, is there a
>> c3 based bubble chart?
>>
>> Am I asking too many questions?
>>
>> Thanks :)
>>
>>
>> On Thu, Jun 9, 2016 at 7:49 AM, Ebonee Farrow <etfar...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm interested in collaborating with the patternfly community and would
>>> like to submit a pattern to the data visualization library for bubble
>>> plots. Are you taking submissions for this chart type?
>>>
>>> Thanks,
>>> Ebonee Farrow
>>>
>>> ___
>>> Patternfly mailing list
>>> Patternfly@redhat.com
>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>
>>
>>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly

Re: [Patternfly] Toast notification positions

[Andres Galante]

Ok, lets stick with what we have. A developer can change the position of
the notification with 2 lines of CSS.

On Mon, Jan 25, 2016 at 11:15 AM, Leslie Hinson <lhin...@redhat.com> wrote:

> Per the page documentation [1], "The notifications should have a
> consistent location in each application. We recommend the top-right of the
> application."
>
> So when you say we should offer more positions, do you mean show actual
> examples of other locations? We purposely did not do this because we are
> making a recommendation to ensure consistency across apps that are using
> PatternFly. That said, we know the app come with there special set of use
> cases hence why we just recommend vs requiring.
>
> Thoughts?
> Leslie
>
> [1] https://www.patternfly.org/patterns/toast-notifications/
>
> On Mon, Jan 25, 2016 at 5:47 AM, Andres Galante <agala...@redhat.com>
> wrote:
>
>> At the moment we are offering the option to position the toast
>> notification at the top right corner by adding the class
>> ".toast-pf-top-right".
>>
>> This follows the patterns recommended position.
>>
>> I've notice today that Angular Material offers top, left, right or bottom
>> positions, so the developer can easily choose where to place the
>> notification: https://material.angularjs.org/latest/demo/toast
>>
>> I was wonder if it is a good idea to add more positioning options to our
>> implementation, or if we should stick to what we recommend.
>>
>> What do you think?
>>
>>
>>
>> ___
>> Patternfly mailing list
>> Patternfly@redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
___
Patternfly mailing list
Patternfly@redhat.com
https://www.redhat.com/mailman/listinfo/patternfly