Drupal Usability IRC Meeting

Bojhan dcmistry: Hey, for todays schedule I was thinking - Usability testing drupal 8 first (you can introduce it?), review of contributed modules second, and finally ux gate?

dcmistry Yeah, same here!except #2. I don't think we have anything specific to review of contribs

Bojhan dcmistry: Ok, about 20 minutes for each should be good. Its probally good to poll how many people have contribs

dcmistry plus, we might not have time to discuss all 3

Bojhan dcmistry: Yhea, it depends a bit on how many people bring contribs - its likely that is something that will grow over time too

dcmistry exactlyso let's do thistalk about #1 and #3but introduce #2 … and gauge interest

Bojhan sounds good

yoroy Bojhan: dcmistry actually, lets do the who's got contrib check first then, so we now from the start and adjust accordingly*know

dcmistry Yea… when introducing the agenda we could do thatnod

jeffnoyes hey guys

yoroy Hi all!

Bojhan yo

andrewmacpherson hello

Druplicon hola

yoroy andrewmacpherson: hi there.

dcmistry Hello everyone!

yoroy waves at some of the new-ish nick names in the room

dcmistry yoroy: and no waves to the others? :P

swentel says hi as well

jeffnoyes 4:00, kick it Dharmesh

yoroy all core devs and ux team members say hi :)

dcmistry Great!Thanks everyone for attending this one

BalintKleri hey everyone!

dcmistry I just want to give a quick idea about today's meetingwe are going to discuss 3 things1. Discuss and talk about how to conduct usability testing for D82. Talk about UX gate

dcmistry and 3. If we have other people who would like to get their designs reviewed in the room, we will review them!

dcmistry Any one in the room who would like to get things reviewed?

andrewmacpherson yes

dcmistry Awesome!

OSInet hi all

andrewmacpherson I have a contrib module, with demo site

yoroy anyone else?

jeffnoyes I also have some revisions to Date Repeat that could get reviewed

BalintKleri will be an opportunity for this two weeks later?

yoroy BalintKleri: yes

dcmistry Great! How about we start with our #1 and #2 and then look at designs?

jeffnoyes yup, I'd say start with #2

BalintKleri yoroy: great, so next time :)

dcmistry BalintKleri: Yes :)

andrewmacpherson review contribs could be on agenda each time

dcmistry Alright! Listening to jeffnoyes

Bojhan jeffnoyes: #2 might be very long, better to do that towards the end.

jeffnoyes isn't it the priority though?

dcmistry Let's start with #2 and then we will jump to #1

jmburnz Is anyone logging this, will it be posted later on

lewisnyman I've got it ;)

Bojhan lewisnyman: thanksdcmistry: ok

lewisnyman Hey guys

jmburnz Hi Lewis

dcmistry http://groups.drupal.org/node/158764

Druplicon http://groups.drupal.org/node/158764 => Defining the Drupal 8 usability gate => 32 comments, 3 IRC mentions

yoroy jeffnoyes: for the smaller core circle yes, but goal is here is attracting new folk too, wouldn't want to bore them with that from the start.anyway, go on

dcmistry A discussion has been started on D.O. on defining usability gates for D8some of you might be familiar with this thread

andrewmacpherson catching up on it now. familiar with overall picture

dcmistry It would be great to get your suggestions as to what would be things that would define the D8 usability gate

jeffnoyes I kind of liked where they landedwith Bojhans last suggestion to include design principles

dcmistry I personally think having "usability testing" is of course importantbut I wonder, how are we going to map it to a time frame

Bojhan dcmistry: Ok, lets keep the usability testing one for last - I think we are pretty established that we want it - but it ties in directly with #1 on how to do it.

lewisnyman I've got a question. Are we going to start thinking about mobile usability going forward?

jeffnoyes I don't think we can say something has to go through testing. All we can do is say that it should be flagged to be tested.

Bojhan lewisnyman: Yes, I dont think it should be a requirement of the UX gate though.

David_Rothstein I really liked Bojhan's wording for the usability testing one, partly because it did not force "usability testing", but rather just said something like "observe users" (which is more approachable).

jmburnz jeffnoyes: when you say where they landed, we're looking at the table in the wiki post

jeffnoyes jmburnz: http://groups.drupal.org/node/158764#comment-535534

Druplicon http://groups.drupal.org/node/158764 => Defining the Drupal 8 usability gate => 32 comments, 4 IRC mentions

jeffnoyes plus bojhans feedback, but at the line item level instead of detailing it out

lewisnyman Bojhan: Why?

Bojhan lewisnyman: Well, its a tricky thing - but I would like to avoid putting anything platform specific in a gate. To me its something thats more a "overall" goal for Drupal, rather than specific to UX.

yoroy jeffnoyes: overall I like bojhans list better in their level of abstraction. The screenshots requirement is a bit silly

OSInet there was a discussion some time ago about "ui levels" (novice/advanced): is this something that is on the table for d8 ?

yoroy jeffnoyes: I guess we need to weight the relative items in the list

OSInet and specifically regarding the ux gate, should every change be considered at these 2 levels

yoroy but what Bojhan proposes is more than a line item in david's tableit focusses on getting people to think through their designwhich is not done by posting screenshots

Bojhan OSInet: I dont think so, generally these gates should apply to any level.

lewisnyman Bojhan: Ok sure, would it become part of the Usability tests or UI guidelines?

yoroy jeffnoyes: give people the questions to evaluate their work / provide rationale

Bojhan OSInet: Its very much still an early-idea, mostly thought about by chx I thinklewisnyman: It could be, definitly.

jeffnoyes yoroy: yeah, I know. I was thiking, I liked how David linked to the user interface guidelines instead of listing them out (which is where i started), so if we're going to link to a larger list of UI guidelines, than it seemed we should do the same with design principles.

David_Rothstein Two of Bojhan's four correspond to ones I had, so the question is mostly about these: "Design for the invisible" and "Allow customisation but give smart defaults"... The choices seem to be keep them separate, or merge them into one (with links to an outside page).

yoroy jeffnoyes: yep

dcmistry I feel it is ONE master checklist

Bojhan Yhea, I am not dead set on the principles in any way - was more of a "lets see how these two principles" fit.

jeffnoyes Bojhan: I was a good suggestion. Principles pickup where guidelines fall down

yoroy jeffnoyes: also, writing docs and guidelines is a huge bottle-neck

Bojhan jeffnoyes: So how do you see "Follow these principles" work? Would we choose a top list of principles?

yoroy rather facilitate the discussion and pick up on that

dcmistry referring to Bojhan's list (Except the last one). I also feel we should put usability heuristic evaluations like "Recognition rather than recall", "Error Prpion" and "Visbility of system status", etc.

jeffnoyes Bojhan: I think so.

Bojhan yoroy: Generally, I think for D8 this could be different though - document as we go.

yoroy Bojhan: yep, my point

Bojhan So, hmm - arn't we turning one gate line item - into many many guidelines to follow then?

jeffnoyes Acquia has 10, but I've always felt that we should limit to 5/6. 10 is too hard to remember. This is especially true for a community effort (imagine the community remembering all 10 that I have listed).

Bojhan We need a way to capture both the complexity, as simplify for developers what they need to think more about.

lewisnyman Here's a good resource http://principles.adactio.com/

jeffnoyes lewisnyman: yup, that's a great resource

dcmistry I actually see it as a 2 point gate

jeffnoyes I think the following hold true, and speak to Bojhans list6. Simple on the surface, powerful underneath Our products appear quite simple on the surface but include powerful features that are easily accessible to those users who want them. Our intent is to invite beginners with a great initial experience while also attracting power users whose excitement and expertise will draw others to the product.

andrewmacpherson Bojhan: a handful of example cases(complex) under each principle (simple) ?

Bojhan Yhea I really loved the wording of that one.

jeffnoyes 9. Don't make me thinkKeep our products consistent. Avoid introducing new interaction patterns when an existing one will perform the same task except when usability is compromised. Prefer self-evident UI over reading documentation. Optimize for scanning over reading. Realize users don't don't make optimal choices, they make satisfactory ones.3. Be worthy of people's trustGood design can go a long way to earn the trust of the people who our products. Establishing trust starts with the basics – making sure the interface is efficient, professional and stable. Actions are easily reversed, ads are clearly identified, terminology is consistent, and users are never unhappily surprised.

jeffnoyes 8. Pave the cowpathsMake decisions based on our observations of actual usage. Where paths are already being formed by behavior, formalize them.

yoroy dmitrig01: what are your 2?

Bojhan jeffnoyes: So to me, our gates are much more in that realm of principles. Obviously we have to operationalize them.

dcmistry 1. Developer has a set of guidelines (suggestions like) where the usability team involvement is not required. 2. Where the usability team jumps in, reviews and does usability study, if required.

yoroy eh dcmistry

dmitrig01 yoroy: ?

yoroy dmitrig01: sorry, meant dcmistry :)

dmitrig01 yoroy: ah, np

jmburnz If you are going to document as you go, and there is no design/style/ UI guide, how can I know I have made an acceptable change to the UI without tagging it as needs review from the UX team

Bojhan jmburnz: http://drupal.org/ui-standardsWell, I think right now it really already flowed very nicely - webchick and dries committed UX changes when they felt it wouldn't require any consultation from the UX team.But what I want, is that more and more people get in the mindset of "UX" and concider a patch, would this pass our UX standards?rather than us needing to stress it each time.

jeffnoyes so are we in agreement that the following are the 4 main gates:

yoroy our biggest win is reading comments where they say "we need somebody to review this" and then they have awesome questions for us

jeffnoyes 1. design principles are followed (link to principles)

jeffnoyes 2. user interface guidelines are followed (link to guidelines)3. Supporting screenshots are supplied4. Relevant patches are flagged for usability testing?

Bojhan erm, not 3

David_Rothstein why not 3?

dcmistry Supporting screenshots are supplied is useful- but it is not always required

jeffnoyes that's what the "when is it needed" for

andrewmacpherson screenshots not always applicable, e.g. information architecture of URLs, or accessibility-related usability

jeffnoyes just like a flag for usability testing isn't always needed.

yoroy It's a silly process thingy in the scheme of things

jeffnoyes may be silly, but think back 3 years ago

Bojhan So, one of the things I mentioned in my last comment is that currently we hardly ever have to ask for screenshots anymore. Its kind of an already established pattern, and yhea as yoroy said in the scheme of things we want people to teach and where these gates are very valuable real eastate its not something we need to push in this thing.

jeffnoyes If we want new people to come and contribute, we need screenshots

andrewmacpherson can we say "useful demo welcome" rather than specifically screenshot?

David_Rothstein yup, just because existing contributors already mostly do it doesn't mean it shouldn't be one of the gates

jeffnoyes hrm, I still regularly find posts without screenshots.

yoroy jeffnoyes: they will have found out long before ever finding these guidelines

andrewmacpherson screencast could be more useful to show a process

OSInet nitpicking, but I think the passive voice ought not to be used in calls to action like this

dcmistry May be 3 could be modified… Tag with necessary elements: needs UX review, needs usability testing, etc ….(and this will include … provide screenshots)

Bojhan David_Rothstein: valid point, but in the scheme of things - I am not sure it is as important.

dcmistry andrew: yes "useful demo" +1

yoroy But I would prefer the item list itself to be a list of principles.

jeffnoyes I'd be deeply saddened if it were to be removed as a gate.

Bojhan jeffnoyes: Why? I am really not encountering it much, for core that is.

jeffnoyes we have to think about new people coming on board too.

yoroy like "Consisitency" - (see guidelines etc.)

andrewmacpherson screenshots/casts are very good for encouraging people to comment

dcmistry Jeffnoyes: I am assuming having a useful demo is obvious and not be considered as a "gate"

yoroy "Pave the cowpaths" as the line item for the usability testing things

David_Rothstein I think the point of the gates is that if I am a contributor who wants to get a patch committed, reading these will guide me in showing what needs to happen in the issue (what I need to do) in order to get the patch in.

Bojhan David_Rothstein: Yhea, I am just thinking - what we really need is "process per gate" kind of description

jmburnz David_Rothstein: exactly, that is what we need, when we're writing a patch etc we need to know what we need to do

jeffnoyes dcmistry: to big I think. Seems a bit much to ask for demos

dcmistry well a demo could be a screenshot

yoroy ALSO: 30 MINUTES LEFT

Bojhan heh :P ok

dcmistry So what's the say gang?

jeffnoyes well, I only heard one objection to my list of 4 - screenshots

dcmistry Screenshot: In/ Out/ Discussion needed?

andrewmacpherson Okay, so 3 is the one we're dancing around. Are we all okay with 1, 2 + 4 ?

jeffnoyes can I beg, plead, and buy you guys beers in london to keep it on the list?

Bojhan dcmistry: Discussion needed I'd say.

jeffnoyes :)

David_Rothstein How about, "in until we come up with 5 better ones" :)

yoroy also also, lets remember there is only 1 usability gate. with multiple checks yes, but 1 gate

David_Rothstein no reason to kick it out if we don't even have 5 yet

jeffnoyes do we have to have 5?

David_Rothstein (of course, we don't have to use the full five)

dcmistry Beer! Hmmm… making me think otherwise :P

Bojhan jeffnoyes: No

dcmistry No, we dont need to have 5

jmburnz I think they are pretty good, what worries me is the documentation being cited behind the points, the ui guide in particular needs a lot of work, if that is committed to being worked on then great, and personally I like screenshots :)

David_Rothstein I'm just saying, I don't think its presence causes harm (does it?), and several of us really want it.jmburnz: agreed.

Bojhan So okeWhat worries me about is 1.Because essentially we are introducing "sub-gates".

dcmistry What about 1?

Bojhan Is there a reason, we couldn't pick 3/4 principles out of the list we would introduce there and simply put them as gates?

OSInet how about adding a requirement to always suggest 2 versions of each patch for A/B testing ?

dcmistry I would not want to restrict to 3/4 principles

dcmistry if that happens that is greatbut just to not sound it as a "sub gate" … I would not want to do that :(

Bojhan OSInet: I think, thats to dependant on the situation to really have as requirement.

OSInet possibly

dcmistry Plus, the "sub-gate" is nothing but a link to another document

Bojhan dcmistry: Well, yes - but we are saying "comply" to these rules too.

David_Rothstein I have to drop off, unfortunately... I would just say I think it's fine to use Bojhan's 2 design principles ("Design for the invisible" and "Allow customisation but give smart defaults") in place of #1, but just be sure those are the only two (or three, or whatever) that you'll ever want :)These gates are probably not things we want to revise often.

Bojhan David_Rothstein: Ohh yhea, totally. heh

dcmistry Thanks, David_Rothstein for attending :)

andrewmacpherson OSInet: A/B testing is a lot of extra work. Wouldn't want to force that on all patches.

jeffnoyes I think we either have sub gates, or we have a huge list of gates.

dcmistry Yes, I would stay away from A/B gates for now!

Bojhan jeffnoyes: So, are the sub gates going to be a huge list or only 5/6 as you mentioned earlier?

Bojhan jeffnoyes: Because if we say, we can make it only 5/6 - its possible to have them as gates.

dcmistry Bojhan: I am assuming it is a short list!

lewisnyman What's the difference between a sub gate and a gate?

jeffnoyes Bojhan: not sure. How many UI guidelines are there?

Bojhan jeffnoyes: I dont know, I could only come up with 2 leading ones atm.

yoroy jeffnoyes: 2 to 3

Bojhan lewisnyman: There is none.

yoroy ui patterns, copy, IA

Bojhan yoroy: oh no,

Bojhan yoroy: more like the " simple on the surface, powerfull beneath", or "be worthy of people's trust"

jeffnoyes I think design principles has to be a subgate. There really just big, overarching concepts. It doesn't seem to be to be a big deal to say that core patches should; pave the cowpaths, be simple on the surface, etc.

Bojhan jeffnoyes: Ok,

dcmistry jeffnoyes: Shouldntoops

yoroy Bojhan: that's a principle? nevermind

dcmistry jeffnoyes: I am assuming it will also include interaction design principlesTIME CHECK: 17 MINUTES TO GO!

Bojhan yoroy: hah, we are mixing words.

jeffnoyes dcmistry: I would think that would be part of UI guidelines

dcmistry okay, sold :)

Bojhan hmm

yoroy Bojhan: I think jeffnoyes asked for the documented guidelines we have: patterns, copy, ia etc

Bojhan But principles will be in a way abstract than? Not operationalized, right?

jeffnoyes I think so.

yoroy Isn't that a pity?

Bojhan yoroy: In a way, yes

jeffnoyes UI guidelines for me are things like interaction patterns. Whereas design principles are project goals.

jmburnz nods

Bojhan jeffnoyes: I mean, in a way its product strategy.

jeffnoyes Bojhan: yup

yoroy 1. Practice your design thinking. 2. Check your work. 3. Post screenshots . 4. Test where necessary

Bojhan Great.jeffnoyes: That is what I was aiming for :)

jeffnoyes But you can veer away from product strategy, which is not a good idea, so therefor it should be a gate

dcmistry 3. Post screenshot s or demo

yoroy 1: principles, 2: guidelines, 3: process 4: verify

Bojhan yoroy: yes.

jeffnoyes dc - no demo

dcmistry jeff: only when requiredsome workflows get complicated...

andrewmacpherson demos are supporting info, not a requirement

jmburnz for accessibility we always run a demo, all the time, constantly updated, for those who cannot apply patches but need to test the UI

dcmistry but, yes I know it is a LOT of work

yoroy jeffnoyes: so what I got from bojhans' post is that it would be so awesome if we could infuse all items on the list with this design strategic thinking.

dcmistry yea, it is not a requirementSeems like we are sold … on our 4 point strategy as of now. Right?

jeffnoyes yoroy: you're loosing me.

Bojhan yoroy: design thinking*

andrewmacpherson I think I meant that some demos won't require much material

yoroy jeffnoyes: basically the way each check in the gate is worded I guess. As a requirement or as a challenge.

yoroy Bojhan: yep, mixup. design thinking

Bojhan jeffnoyes: Yhea, its mostly in the wording. But not say something like "Usability testing is performed, and the tests pass" should say "Observe users to better understand how your UI changes are used." - We want people to make more informed choices, not checkoff requirements.which I guess is the opposite of the docs-gate

jmburnz It would be good to know when usability testing is required, and when we are required to tag things UX review needed, I know these things are not black and white but some guide would be useful

Bojhan jmburnz: true, I think for ux testing we can define it better.

dcmistry jmburnz: Agree. we should have a rough guideline as to how to tag

jeffnoyes Wait, you're going to ask developers to observe users?

Bojhan hmm, given our time. andrewmacpherson can you already drop links to your module and demo? We can probally review in parallel to this discussion.

andrewmacpherson yep

Bojhan jeffnoyes: Sure

andrewmacpherson http://drupal.org/project/themesettings_extras

jeffnoyes Maybe Im missing the point, but this is a "gate" which means you cannot pass until you do X, Y, Z

dcmistry Bojhan: NOOOOOOOOOOOOOOOOOOOOOOO

andrewmacpherson demo site at www.drupal.fuzzbomb.netnext itme will dotime,

Bojhan andrewmacpherson: no problem,andrewmacpherson: already lookingjeffnoyes: Yes, but how can we say - you can not pass untill you do 1? follow design principles.

dcmistry Bojhan: The core of usability testing is that we have unbiased data from OUR real usershaving say "observe users" could be misleading

jeffnoyes Bojhan, so long as our design principles are tactile, I think you can do that. For example...you cannot pass, if you haven't paved the cowpaths (your inventing something without looking at how people are actually using the product). Or...Or, you cannot pass if you're exposing complexity on the surface

lewisnyman Yeah sounds good

jeffnoyes To your point, maybe fluffier principles like "be worthy of peoples trust" need to go

Bojhan jeffnoyes: agreeddcmistry: My point with the wording is, we want people to make informed decisions - not checkoff boxes. Thats the whole idea, behind me changing wording.dcmistry: Its not about unbiased data from our real users, you get that if you follow the guidelines of our requirement right?

jeffnoyes More examples (don't make me think)... You cannot pass if you're not using existing patterns, and forcing people to learn new ways of doing things.

yoroy jeffnoyes: yep those are good.

dcmistry Bojhan: Yes, that is fine. But it should not mislead them they can just "observe users" and get it done. Even after following UI guidelines there are always usability issues which come up, just less in number (hopefully)

jeffnoyes So it needs to be a goal that principles are tactile

Bojhan dcmistry: ohh sure, heh

yoroy So my latest version of The List is1: Principles - practice your design thinking2: Guidelines - check your work against core standards3: Process: post screenshots4: Verify - test where necessary

jeffnoyes wow, that was some rapid typing

Bojhan jeffnoyes: hah, that narrows down our list of principles conciderably as well.

yoroy jeffnoyes: or slow pasting :)

jeffnoyes Sold.

Bojhan So is the next step, 1. hash out the details more?

dcmistry :)We ran out of time :(

Bojhan 2. hash out the wording, + concider what is needed to make this requirement work3. process, discuss some more?

yoroy yep

Bojhan 4. figure out the guidelines/ wording?I can probally write a better summary in the issue though :P

dcmistry Yea, the next steps sounds good!

Bojhan awesome

jeffnoyes Looks like we're at time, and I have to move onto other things. In the spirit of #3, if anyone is interested in what I've done with Date Repeat, feel free to take a look and comment: https://docs.google.com/a/acquia.com/document/d/1HgZNRoFXc6JMzPCrP4EVMZS...

andrewmacpherson will do.

Bojhan andrewmacpherson: looking at it now, btw

yoroy jeffnoyes: thanks for attending

dcmistry Andrew: feedback: THe "Switch Theme" is displayed all the time. But, most often users would not be wanting to switching all the time. Am I missing something?

jeffnoyes Thanks for listening. :)

andrewmacpherson the list of 4 looks good. be good to see what the rest of the community think.ignore the switch theme. taht's mainly there for mucking about with the touch icons module.dive into the theme settings pages after logging in

dcmistry Andrewmacpherson: oh okay

yoroy jeffnoyes: where did you get that idea? :)

Bojhan andrewmacpherson: So, basically the idea is to use vertical tabs to better group the options on the theme setting page, correct?

jmburnz Is the meeting shifting back the #1 now, Usability testing in D8 - is that right?

andrewmacpherson vertical tabs is one of the demos. basically bring an exsting patern onto theme settings pagethe other one is the radio buttons for logo/faviconi thought it was odd that logo and favicon needed TWO checkboxes each, and these are in different fieldsets.

jeffnoyes yoroy: pave the cowpaths

Bojhan jmburnz: I think we are basically over time, so probally pushing that of for our next meeting.

dcmistry jmburnz: yep!

andrewmacpherson so i removed toggle logo + favicon checkboxes

Bojhan But if dcmistry is around, we can atleast chat around it? I guess

dcmistry I am around...

yoroy jeffnoyes: heh, no. that we were listening ;-)

jeffnoyes oh :), I thought you were talking about Date Repeat

Bojhan andrewmacpherson: lets start with http://drupal.org/node/1087100

Druplicon http://drupal.org/node/1087100 => Vertical tabs => 0 comments, 1 IRC mention

andrewmacpherson looking..,

Bojhan andrewmacpherson: So I like your improvements to the indiviual form elements, I am not completely sure on the useage of vertical tabs.

yoroy jmburnz: if you have questions though, drop 'm in here

Bojhan andrewmacpherson: Because I am going to this page to see an overview of the settings, by putting them in a vertical tab we are basically hiding the functionality that you are going to this page for.andrewmacpherson: And its not really grouping similair data, each tab is very different from the other.

yoroy jeffnoyes: so that first bit with capturing all module dependencies into a single feature is probably Drupal 9 yeah

andrewmacpherson similar data example would be the user email settings in D7?

Bojhan andrewmacpherson: Yhea, all e-mail things are captured in one VTandrewmacpherson: but other config is still on top

andrewmacpherson i think the logo and favicon meet that.

jeffnoyes yoroy, we do it in Drupal Gardens now, but it's always a performance question

andrewmacpherson the toggle VT doesn't

Bojhan andrewmacpherson: Yhea, what I was thinking actually - what if you loose all grouping currently on the page, and think about a more intelligent way to group it - just in VT's.oopsin fieldsetsandrewmacpherson: For example group display of the "main site parts" site name, site slogan and logo.

yoroy jeffnoyes: ah, yeah, imagine that gets resource hungry real quick

Bojhan andrewmacpherson: and group menu's say, primary linnks and secondary links

andrewmacpherson I'm gonna tun off the VT module so we can see how it looks with just the radios mod

Bojhan andrewmacpherson: And then move all "module speciific" groupings into a VT?

andrewmacpherson yes, like the menus ideaone area that it also affects is with theme-specific settings, which i imagined as a separate VT group

Bojhan andrewmacpherson: you have an example?andrewmacpherson: ahh wait I see

andrewmacpherson also contrib modules are starting to add fieldsets to themesettings. Touch_icons, noggin

Bojhan andrewmacpherson: crazy ideaandrewmacpherson: Hide all settings, but theme specific settings on individual themes.

andrewmacpherson design kti also adds a fieldsetdesign kit

Bojhan andrewmacpherson: I mean, since this is an experiment, you could hide or atleast collapse under something all settings under a theme which are not specific to that theme.andrewmacpherson: Not sure if they are more commonly used?

Bojhan andrewmacpherson: kind of like "set globals" but override on a per case basis, only if collapsed.

andrewmacpherson yes, that's why i was thinking of one VT block for core settings, and one for theme-specific settingsalthough something like D7 build modes or Views 3 default/over-rides might work too

dmitrig01 jeffnoyes: nice work on the date repeat. What about doing something like "Repeat every [1|2|3 etc] [days|weeks|months]" ?

Bojhan andrewmacpherson: yheaandrewmacpherson: I think the biggest problem is using VT, because its soo prominent

yoroy andrewmacpherson: Bojhan we'd have to get an idea about if what now are 'Global' settings really are the ones that people keep consistent across multiple themes

andrewmacpherson yoroy: that's a good point

Bojhan yoroy: Well, if you have say a "global settings" part of the page collapsed in a fieldset?yoroy: You can have it disabled, and show an override button? dunno crazy idea I guess :)

andrewmacpherson one of the things I like about VT is that it's collapsed but has a summary view available. "Custom favicon" is very easy to scan.but there might be another way of presenting a summary of settings, with an over-ride buttonfield formatter settings does this

Bojhan andrewmacpherson: views does this.

andrewmacpherson yes, both different though

yoroy andrewmacpherson: but a whole tab for just the favicon feels a bit much no?

andrewmacpherson views 3 is a good step forward, perhaps some patterns there could be used around core

Bojhan yoroy: I suggested a overall regrouping of settings, per "part of the page" or per module.

andrewmacpherson yoroy: collapsing favicon settings makes sense because the actual settings widgets take up a fair amount of space.you only need the widget if you are intending to change a setting

yoroy andrewmacpherson: is it in the scope of your module to do this info-architectural re-jiggering we're talking about here?

Bojhan lewisnyman: Hey, I think we are basically done with the meeting. Can you paste logs in the groups topic?

andrewmacpherson the summary of favicon settings could be better. show the actual favicon.

lewisnyman I will give it a go

yoroy andrewmacpherson: would be great to have the thumbnail of the theme in sight