After all the discussion on branding, and talking with some other members of the Fedora Design team, it seems that the option for branding on Fedora 21 Workstation of putting the logo on the wallpaper (superimposed using a shell extension), is the best option.
Other options such as putting icons and text in the topbar can directly impact the user experience, so any of those changes will need to be user-tested, something that we don't really have time for in this release cycle, so we will need to reconsider these options with some relevant user testing data for the next release cycle.
cheers, ryanlerch
On Mon, Nov 17, 2014 at 02:23:41PM -0500, Ryan Lerch wrote:
After all the discussion on branding, and talking with some other members of the Fedora Design team, it seems that the option for branding on Fedora 21 Workstation of putting the logo on the wallpaper (superimposed using a shell extension), is the best option.
Other options such as putting icons and text in the topbar can directly impact the user experience, so any of those changes will need to be user-tested, something that we don't really have time for in this release cycle, so we will need to reconsider these options with some relevant user testing data for the next release cycle.
I can't think of a reason not to do better user testing, if we can. And given the late point in the schedule, +1 from me.
Is the extension packaged so it can be included?
AIUI, the logo disappears if the user opts (or has opted) to change the background. Is that correct?
On 11/17/2014 03:03 PM, Paul W. Frields wrote:
On Mon, Nov 17, 2014 at 02:23:41PM -0500, Ryan Lerch wrote:
After all the discussion on branding, and talking with some other members of the Fedora Design team, it seems that the option for branding on Fedora 21 Workstation of putting the logo on the wallpaper (superimposed using a shell extension), is the best option.
Other options such as putting icons and text in the topbar can directly impact the user experience, so any of those changes will need to be user-tested, something that we don't really have time for in this release cycle, so we will need to reconsider these options with some relevant user testing data for the next release cycle.
I can't think of a reason not to do better user testing, if we can. And given the late point in the schedule, +1 from me.
Is the extension packaged so it can be included?
AIUI, the logo disappears if the user opts (or has opted) to change the background. Is that correct?
Yes, the versions of the extension I saw only showed the logo on the default wallpaper.
--ryanlerch
On Mon, Nov 17, 2014 at 03:07:26PM -0500, Ryan Lerch wrote:
On 11/17/2014 03:03 PM, Paul W. Frields wrote:
On Mon, Nov 17, 2014 at 02:23:41PM -0500, Ryan Lerch wrote:
After all the discussion on branding, and talking with some other members of the Fedora Design team, it seems that the option for branding on Fedora 21 Workstation of putting the logo on the wallpaper (superimposed using a shell extension), is the best option.
Other options such as putting icons and text in the topbar can directly impact the user experience, so any of those changes will need to be user-tested, something that we don't really have time for in this release cycle, so we will need to reconsider these options with some relevant user testing data for the next release cycle.
I can't think of a reason not to do better user testing, if we can. And given the late point in the schedule, +1 from me.
Is the extension packaged so it can be included?
AIUI, the logo disappears if the user opts (or has opted) to change the background. Is that correct?
Yes, the versions of the extension I saw only showed the logo on the default wallpaper.
OK, a lot of quick action on this, on the part of several people yesterday and this morning. Here's what we discovered:
Package bug: https://bugzilla.redhat.com/show_bug.cgi?id=1161637 Upstream git: https://git.fedorahosted.org/cgit/background-logo-extension.git/
(1) The SRPM in the bug appears to be *newer* than git (includes e.g. prefs.js, control utility). Maybe something wasn't pushed? However, the SRPM seems like it should work.
(2) We need to package a wordmark, since that works visually better than the Fedora infinity-bubble logomark. Also, from the mockups, an < 100% opacity was desirable. Ryan has sent that on to Spot to add to fedora-logos.
(3) The package needs a .gschema.override file to point to the new logo. That seems like the right thing to do for a distro-specific change like this. I wasn't able to find fmuellner on line yesterday or this morning, so given the freeze, Stephen Gallagher was planning to help us with packaging since he's a provenpackager. I pasted this: http://fpaste.org/151778/16319651/
If anyone has concerns or suggestions, please add them ASAP... the freeze is on today, so we may end up needing a QA exception to get this stuff done.
On Tue Nov 18 2014 at 3:16:09 PM Paul W. Frields stickster@gmail.com wrote:
(1) The SRPM in the bug appears to be *newer* than git (includes e.g. prefs.js, control utility). Maybe something wasn't pushed?
Yes, the snapshot was from my local tree. The prefs was a late-night hack from the previous night, and I wanted to get at least some minimum feedback that those options made sense.
If I can read this as a confirmation, I'll push the commits in question.
(2) [...] Also, from the mockups, an < 100% opacity was desirable.
Will this be handled by the artwork, or do we want another option?
(3) The package needs a .gschema.override file to point to the new
logo. That seems like the right thing to do for a distro-specific change like this.
Yes, that was the idea.
On 11/18/2014 09:44 AM, Florian Müllner wrote:
On Tue Nov 18 2014 at 3:16:09 PM Paul W. Frields <stickster@gmail.com mailto:stickster@gmail.com> wrote:
(1) The SRPM in the bug appears to be *newer* than git (includes e.g. prefs.js, control utility). Maybe something wasn't pushed?
Yes, the snapshot was from my local tree. The prefs was a late-night hack from the previous night, and I wanted to get at least some minimum feedback that those options made sense.
If I can read this as a confirmation, I'll push the commits in question.
(2) [...] Also, from the mockups, an < 100% opacity was desirable.
Will this be handled by the artwork, or do we want another option?
(3) The package needs a .gschema.override file to point to the new logo. That seems like the right thing to do for a distro-specific change like this.
Yes, that was the idea.
If the opacity can be done in the extension, that would work better IMHO, that way we can ship an SVG in the fedora-logos package that has no transparency (in case it needs to be used elsewhere)
cheers, ryanlerch
On Tue Nov 18 2014 at 4:21:38 PM Ryan Lerch rlerch@redhat.com wrote:
If the opacity can be done in the extension, that would work better IMHO
OK, I'll have that in a bit.
On Tue, Nov 18, 2014 at 02:44:40PM +0000, Florian Müllner wrote:
On Tue Nov 18 2014 at 3:16:09 PM Paul W. Frields stickster@gmail.com wrote:
(1) The SRPM in the bug appears to be *newer* than git (includes e.g. prefs.js, control utility). Maybe something wasn't pushed?
Yes, the snapshot was from my local tree. The prefs was a late-night hack from the previous night, and I wanted to get at least some minimum feedback that those options made sense.
If I can read this as a confirmation, I'll push the commits in question.
FWIW, I thought you did a nice job with an unexpected request.
(2) [...] Also, from the mockups, an < 100% opacity was desirable.
Will this be handled by the artwork, or do we want another option?
It's handled by the artwork currently. I'm not sure whether it merits an exposed control. But being able to see the results in the live preview would make it easier to tune that feature, if you decided to add it.
(3) The package needs a .gschema.override file to point to the new logo. That seems like the right thing to do for a distro-specific change like this.
Yes, that was the idea.
Awesome! :-)
On 11/18/2014 03:16 PM, Paul W. Frields wrote:
OK, a lot of quick action on this, on the part of several people yesterday and this morning. Here's what we discovered:
Package bug: https://bugzilla.redhat.com/show_bug.cgi?id=1161637 Upstream git: https://git.fedorahosted.org/cgit/background-logo-extension.git/
(1) The SRPM in the bug appears to be *newer* than git (includes e.g. prefs.js, control utility). Maybe something wasn't pushed? However, the SRPM seems like it should work.
Excellent, thanks for looking into this! Florian was waiting on approved design before doing a final upstream release and now that we have it, he should be able to do the release.
(2) We need to package a wordmark, since that works visually better than the Fedora infinity-bubble logomark. Also, from the mockups, an < 100% opacity was desirable. Ryan has sent that on to Spot to add to fedora-logos.
Great -- we'll need a new fedora-logos build for the installer branding anyway.
(3) The package needs a .gschema.override file to point to the new logo. That seems like the right thing to do for a distro-specific change like this. I wasn't able to find fmuellner on line yesterday or this morning, so given the freeze, Stephen Gallagher was planning to help us with packaging since he's a provenpackager. I pasted this: http://fpaste.org/151778/16319651/
It's a fedora-specific package anyway, I think we should be able to avoid the overrides and just default to the correct logo. Florian, what do you say?
Another thing we'll need is to include an override somewhere to enable the extension by default. fedora-release-workstation seems like an appropriate place -- I'll send a patch to dgilmore a bit later today that adds the override if nobody comes up with a better way of doing it.
If anyone has concerns or suggestions, please add them ASAP... the freeze is on today, so we may end up needing a QA exception to get this stuff done.
Yes, we're already frozen now, definitely need a QA exception.
On Tue, Nov 18, 2014 at 03:48:47PM +0100, Kalev Lember wrote:
On 11/18/2014 03:16 PM, Paul W. Frields wrote:
OK, a lot of quick action on this, on the part of several people yesterday and this morning. Here's what we discovered:
Package bug: https://bugzilla.redhat.com/show_bug.cgi?id=1161637 Upstream git: https://git.fedorahosted.org/cgit/background-logo-extension.git/
(1) The SRPM in the bug appears to be *newer* than git (includes e.g. prefs.js, control utility). Maybe something wasn't pushed? However, the SRPM seems like it should work.
Excellent, thanks for looking into this! Florian was waiting on approved design before doing a final upstream release and now that we have it, he should be able to do the release.
(2) We need to package a wordmark, since that works visually better than the Fedora infinity-bubble logomark. Also, from the mockups, an < 100% opacity was desirable. Ryan has sent that on to Spot to add to fedora-logos.
Great -- we'll need a new fedora-logos build for the installer branding anyway.
Correct, I *think* we're waiting on that from Spot.
(3) The package needs a .gschema.override file to point to the new logo. That seems like the right thing to do for a distro-specific change like this. I wasn't able to find fmuellner on line yesterday or this morning, so given the freeze, Stephen Gallagher was planning to help us with packaging since he's a provenpackager. I pasted this: http://fpaste.org/151778/16319651/
It's a fedora-specific package anyway, I think we should be able to avoid the overrides and just default to the correct logo. Florian, what do you say?
Another thing we'll need is to include an override somewhere to enable the extension by default. fedora-release-workstation seems like an appropriate place -- I'll send a patch to dgilmore a bit later today that adds the override if nobody comes up with a better way of doing it.
I don't know another way.
If anyone has concerns or suggestions, please add them ASAP... the freeze is on today, so we may end up needing a QA exception to get this stuff done.
Yes, we're already frozen now, definitely need a QA exception.
I put the Fedora package review bug on the tracker for proposed exceptions. It sounds like we need another bug for the fedora-release-workstation changes -- that will make it easiest to track I think.
desktop@lists.stg.fedoraproject.org