Closed Bug 629699 Opened 13 years ago Closed 12 years ago

Implement Phase 2 of universal header

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: davidwboswell, Assigned: sgarrity)

References

Details

(Whiteboard: r=101065,101070,101255,101256 b=trunk)

Attachments

(3 files, 1 obsolete file)

Wireframe for Universal Tab
41.95 KB, image/png
Details
Universal Tab on mozilla.org design
455.99 KB, image/png
Details
Outline that appeas around the boxes
15.93 KB, image/png
Details 
Opening bug to track phase 2 of universal header project -- rolling out the mozilla.com/AMO/SUMO header to other sites in the Mozilla universe.  For reference, phase 1 is being tracked in bug 619986.
The next website task force meeting is this Thursday -- just pinging this bug to see if there is any new information we'd like to present at the meeting to move  this proposal forward.
Assignee: nobody → smartell
Gonna throw the link in here for my tracking purposes: 
https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab#Expanded_Content
Sean, just pinging the bug to see if there's an update on the universal header designs.  Thanks.
Adding Jason, so he can follow along and work with Sean on how the tab will work with mobile.
The next task force meeting is next Thursday on June 30 -- would it be possible to get some mockups of the expanded universal tab ready by then so we can get feedback from the group?
This has slipped due to brand toolkit Q2 goals, but I will be diving deep into this shortly and it will be added as a Q3 goal.
Sean, thanks for the update.  When you know more about when you'll have something, let me know so I can figure out the best way to get wider input.
Reassigning to John for feedback.

John,

I'd love to implement a very experimental version of this on /firefox to coincide with the launch of Apps Marketplace. We could use this as an opportunity to gather user feedback and data to improve upon for a more permanent future solution.

Recommendation for a static version of the tab for /firefox site:

Mozilla Foundation (link to http://www.mozilla.org/foundation/about.html)

Mozilla Labs (link to https://mozillalabs.com/) OR WebFwd (https://webfwd.org/en-US/ since it has the tab)

Mozilla Products

* Firefox (link to http://mozilla.org/firefox)
* Firefox for Mobile (link to http://www.mozilla.org/mobile/)
* Apps Marketplace (link to ...)
* Add-ons Marketplace (https://addons.mozilla.org/firefox/)
* Thunderbird (http://mozilla.org/thunderbird)

Mozilla Developer Network (https://developer.mozilla.org/)

*Desktop (link tohttps://developer.mozilla.org/web)
*Mobile (link to https://developer.mozilla.org/mobile)
*Add-ons (link to https://developer.mozilla.org/addons)
*Demos (link to https://developer.mozilla.org/demos/)

Let me know your thoughts - we can work with Steven on a prototype to test a bit.
Assignee: smartell → jslater
Thanks for getting this conversation started again...this is definitely a topic we'll need to resolve soon, so it's good to start discussing now.

Having said that, I don't think the list in comment #8 is quite the right breakdown for the universal header. I'd like to start by dividing our web universe into broad sections...ideally then each of those sections would link to a site that would have more info in its own nav (for example, the Firefox link in the header would be a level up from the nav on the Firefox site itself; same deal with the Mozilla link and the mozilla.org nav).

With full knowledge that this list is wrong in many ways, here are some candidates that could go in the header:
- Mozilla (links back to mozilla.org, which has info about the project in general, the community, getting involved, etc)
- Firefox (links back to mozilla.org/firefox, which has info about desktop, mobile, add-ons, support)
- Developers (links to MDN)
- Labs (links to Labs...includes things like WebFWD, BrowserID [for now], possibly Thunderbird)
- maybe an Other Products link?
- eventually Apps
 
Not sure if we'd want to specifically call out Get Involved or Community at this level - on one hand they're very important and are things we should draw more attention to, but on the other hand that's what directing people to mozilla.org is for. Also, sites like Add-ons, which are clearly very important but also could be spread among different product groups, are hard to fit in.

Other open questions:
- what's the interaction model for the tab? Do you get the expanded version by clicking on or rolling over? 
- how will this tab work on phones and tablets?
- this might just add clutter, but what about having a section off to the side for a 'featured site' or some other way of calling out something that might otherwise be buried?
- how many people are clicking on the current tab (from mozilla.org/firefox)?

Would love to hear from the others on the cc list as how best to organize this...keeping the top level list fairly short while also being able to expose all the concepts within for easy discoverability and navigation is the key.
> Would love to hear from the others on the cc list as how best to organize
> this...keeping the top level list fairly short while also being able to
> expose all the concepts within for easy discoverability and navigation is
> the key.

I agree with Sean's approach of getting something out there to generate ideas and suggestions for a more permanent solution.

I also agree with John about creating broad sections that people can access as hubs to dive in to specific parts of the project.  However, I don't think we need to have this worked out now -- we could do an experiment with almost any content here to get the discussion going again.

I would like to see a Get Involved link as one of the hubs since this in one of those broad areas that people can dive into to find out how to contribute to any project area.  

I'd also like to move away from thinking of www.mozilla.org as the place for finding out about the community since the community is not something that's separate to what's going on at Mozilla.  Community is baked into everything, so www.mozilla.org should be seen as a hub to all other hubs and not a hub to just some content about community (whatever that would be).
Attached image Wireframe for universal tab (obsolete) — 
Revised universal tab with IA and content
David, John, and Sean, I've taken your feedback in comment 9 and comment 10 and merged into a revision in comment 11.

Can you share your thoughts?

Next steps:

*revise content per your thoughts
*code a static prototype and test...
---on a small % of /firefox traffic
---on a focus group with user and peer feedback
---take what we learn and iterate

Also, if we want to start out with 2-3 versions we can do that in the testing cycle, so no ideas need to be left behind at this point.
(In reply to mcbmoz from comment #12)
> David, John, and Sean, I've taken your feedback in comment 9 and comment 10
> and merged into a revision in comment 11.
> 
> Can you share your thoughts?

I think the important thing is to just put a mockup out there with any content, so the content in comment #11 is fine for that.  

I have some thoughts about what goes there, but it would be helpful to go ahead and restart a wider discussion around this based on a mockup.
(In reply to David Boswell from comment #13)
> (In reply to mcbmoz from comment #12)
> > David, John, and Sean, I've taken your feedback in comment 9 and comment 10
> > and merged into a revision in comment 11.
> > 
> > Can you share your thoughts?
> 
> I think the important thing is to just put a mockup out there with any
> content, so the content in comment #11 is fine for that.  
> 
> I have some thoughts about what goes there, but it would be helpful to go
> ahead and restart a wider discussion around this based on a mockup.

David, just pinged John for some guidance. Thanks for your comment 13. If you can elaborate a bit on where you would like this posted, for how long, and in what format that would be very helpful to me. 

Going outside of bugzilla is a new workflow that I haven't done before, so I want to make sure I've got more support and am prepared with a communications plan for community interactions.
Sure, happy to help.

In general, I think it's easier to get buy-in on a concept like this that we want to roll out to all sites if we present a rough draft at first instead of a more polished proposal or a coded prototype.  People want to have an opportunity to have their voice heard and incorporated.

So, my suggestion is create a mockup and use that to get buy-in.  If you jump ahead to coding this, people may assume the design and content has been finalized.

When the mockup is ready I'd take it to the website taskforce and discuss there, blog about it, mention it on a Monday All Hands, post it to Yammer, etc.  In those communications, I'd also link to a wiki or etherpad page with the contents of the header and ask people to add their own suggestions there.
(In reply to David Boswell from comment #15)
> Sure, happy to help.
> 
> In general, I think it's easier to get buy-in on a concept like this that we
> want to roll out to all sites if we present a rough draft at first instead
> of a more polished proposal or a coded prototype.  People want to have an
> opportunity to have their voice heard and incorporated.

OK, makes sense. I was proposing that we run some tests on a small % of the firefox product site, so my approach may be a little different. I understand now how you are envisioning this.

> 
> So, my suggestion is create a mockup and use that to get buy-in.  If you
> jump ahead to coding this, people may assume the design and content has been
> finalized.
> 

Makes sense. If John gives us a +1 I'll open a design bug for Sean.

> When the mockup is ready I'd take it to the website taskforce and discuss
> there, blog about it, mention it on a Monday All Hands, post it to Yammer,
> etc.  In those communications, I'd also link to a wiki or etherpad page with
> the contents of the header and ask people to add their own suggestions there.

Makes sense. Since this was initially your project, I'd like to ask if you want to continue on as it's lead and advocate with my support or if you think I can do it with your support? I don't have the communications savvy with the community that you do, so I might be at a deficit right now, but willing to learn. LMK.
(In reply to mcbmoz from comment #16)
> Makes sense. Since this was initially your project, I'd like to ask if you
> want to continue on as it's lead and advocate with my support or if you
> think I can do it with your support? I don't have the communications savvy
> with the community that you do, so I might be at a deficit right now, but
> willing to learn. LMK.

I'll be happy to help you with this.
(In reply to David Boswell from comment #17)
> (In reply to mcbmoz from comment #16)
> > Makes sense. Since this was initially your project, I'd like to ask if you
> > want to continue on as it's lead and advocate with my support or if you
> > think I can do it with your support? I don't have the communications savvy
> > with the community that you do, so I might be at a deficit right now, but
> > willing to learn. LMK.
> 
> I'll be happy to help you with this.

#fb
Quick thoughts:
- mockup in comment #11 looks like a great start. I'm sure it'll evolve along the way, but this is a really good foundation. My main quibble is that perhaps Labs doesn't belong at the same level as the others, but we can figure that out.

- +1 for David's suggested actions in comment #15

- +1 for Chrissie taking the lead but David offering guidance along the way

I think the main thing to communicate is that this is a rough pass and we just needed to put something together as a starting point. It's a tricky balance b/c we need something for people to react to, but we also don't want people to overreact by feeling that it's a done deal.

I can advise on this too...am on PTO tomorrow, but want to talk more next week? Perhaps at our 1:1?
Sean, assigning back over to you to add your comp here after tomorrow's One Mozilla meeting. I'll ping you! 

For community discussion, we'll also be posting over at three other locations:

* http://onemozilla.org and on the wiki at:
* https://wiki.mozilla.org/One-Mozilla-Project
* https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab

And, presenting at an upcoming community marketing call, so please stay tuned.
Assignee: jslater → smartell
Target Milestone: --- → 4.5
Blocks: 704365
OS: Mac OS X → All
Hardware: x86 → All
Sean, friendly ping on this. Can you attach the PSD and a PNG here. 

Then I'll assign to Steven for implementation on mozilla.org and mozilla.org/firefox sites to a small test % of traffic.

I'll also post the plan and graphic over on onemozilla.org.

Thanks!
Chrissie: A few questions:

1) Who should we talk to about how this can/should be A/B tested? It's not as simple as most single-page A/B tests.

2) Has the design had an l10n review? Any issues/complications with localization?
(In reply to Steven Garrity from comment #22)
> Chrissie: A few questions:
> 
> 1) Who should we talk to about how this can/should be A/B tested? It's not
> as simple as most single-page A/B tests.

I'll be working with you on this around the Sitespect issue. (I've got something in my back pocket!)

> 
> 2) Has the design had an l10n review? Any issues/complications with
> localization?

This is en-US only for now. We won't move forward on l10n until after we've done testing and optimized, and then we'll do this over on Bedrock. Think of this build as more of a prototype than a final product.

Sean, pinging for the files :-)
(In reply to mcbmoz from comment #23)
> (In reply to Steven Garrity from comment #22)
> > 1) Who should we talk to about how this can/should be A/B tested? It's not
> > as simple as most single-page A/B tests.
> I'll be working with you on this around the Sitespect issue. (I've got
> something in my back pocket!)

Can you elaborate? I need to figure out how to implement this header and our current header simultaneously without duplicating too much code.
(In reply to Steven Garrity from comment #24)
> (In reply to mcbmoz from comment #23)
> > (In reply to Steven Garrity from comment #22)
> > > 1) Who should we talk to about how this can/should be A/B tested? It's not
> > > as simple as most single-page A/B tests.
> > I'll be working with you on this around the Sitespect issue. (I've got
> > something in my back pocket!)
> 
> Can you elaborate? I need to figure out how to implement this header and our
> current header simultaneously without duplicating too much code.

Steven, pinging you over email. HIgh-level summary is that Sitespect can manage the A/B testing without us needing to update the current site, so ideally we'll deploy a working prototype inside of that tool. From there, we'll work with James to build the real deal on Bedrock. Working to keep it simple and not waste good code :-)
Target Milestone: 4.5 → 1.4
Just an updated wireframe, content very much in motion :-)
Attachment #566937 - Attachment is obsolete: true
We've got an initial implementation working locally here and while building it out, we came up with a few questions/issues.

Each site using the universal tab would include three elements:

1. A static link with a particular ID pointing to a (yet to be created) page that contains the same contents as the opened panel. This link will serve as a non-javascript fallback. Something like:
	<a id="tabzilla" href="http://www.mozilla.org/tab/">mozilla</a>

2. A CSS file (either included on the client side, or pulled in and merged/minified on the server side to avoid the additional HTTP request) to style the closed tab.

3. A javascript include (probably included in the footer) that would replace the static tab link with panel open/close toggle behavior.

This javascript include would also pull in the actual contents of the tab panel, including HTML/CSS, possibly embedded directly in the Javascript to avoid additional HTTP requests.

Some issues & questions:

If we slide the contents of the page down when opening the tab (which I think we should), there are some CSS issues this can raise for sites including the tab:
a) Any background images that vary vertically (as most do on mozilla.org/firefox) will have to be attached to an element inside the page rather than the <body> element.
b) Similarly, any absolutely positioned elements will have to be attached to an element in the page (probably a wrapper div) rather than the <body> element.

The search input is very low contrast - perhaps too low?

The search has no submit button - should there be one? If so, perhaps a subtle magnifying class icon overlayed inside the search input box like http://teamtreehouse.com/ ? Or maybe we don't need a submit button at all.

Should we include the Open Sans font ourselves, or perhaps require the implementing site to include it? (the two weights used are about 32Kb for the basic latic charset, larger for other locales).

Can we expect jquery from the client site? Include it ourselves? Or work directly in Ye-Olde-Javascript to avoid the dependency?

Should we use only CSS3 for the animation of the tab open/close, which would mean no animation (just instant open/close) in IE, or should we use jQuery animation? I would suggest we start with CSS3 and use jQuery animation as a fall-back.

I'm sure we'll come up with some other issues as we get further into implementation. We haven't looked at pulling in about:home snippets into the promo area yet. I would suggest we start with something static and make that a post 1.0 feature.

While these elements (js/images/css) would likely be hosted on mozilla.org (and the associated CDN), we should treat the mozilla.org and mozilla.org/firefox sites as we would any other sites implementing the tab.
(In reply to Steven Garrity from comment #28)
> We've got an initial implementation working locally here and while building
> it out, we came up with a few questions/issues.
> 
> Each site using the universal tab would include three elements:
> 
> 1. A static link with a particular ID pointing to a (yet to be created) page
> that contains the same contents as the opened panel. This link will serve as
> a non-javascript fallback. Something like:
> 	<a id="tabzilla" href="http://www.mozilla.org/tab/">mozilla</a>

Steven, should I open a new bug and create a dependency on this bug for that future page?

> 2. A CSS file (either included on the client side, or pulled in and
> merged/minified on the server side to avoid the additional HTTP request) to
> style the closed tab.
> 
> 3. A javascript include (probably included in the footer) that would replace
> the static tab link with panel open/close toggle behavior.
> 
> This javascript include would also pull in the actual contents of the tab
> panel, including HTML/CSS, possibly embedded directly in the Javascript to
> avoid additional HTTP requests.
> 
> Some issues & questions:
> 
> If we slide the contents of the page down when opening the tab (which I
> think we should), there are some CSS issues this can raise for sites
> including the tab:
> a) Any background images that vary vertically (as most do on
> mozilla.org/firefox) will have to be attached to an element inside the page
> rather than the <body> element.
> b) Similarly, any absolutely positioned elements will have to be attached to
> an element in the page (probably a wrapper div) rather than the <body>
> element.
> 
> The search input is very low contrast - perhaps too low?

Agreed, too low. Can you adjust on your end?

> The search has no submit button - should there be one? If so, perhaps a
> subtle magnifying class icon overlayed inside the search input box like
> http://teamtreehouse.com/ ? Or maybe we don't need a submit button at all.

Great catch on the usability front, we do need a submit mechanism for search, and the magnifying glass overlay would be a great addition to the design. We're word-heavy, so either that or the word "go."

> Should we include the Open Sans font ourselves, or perhaps require the
> implementing site to include it? (the two weights used are about 32Kb for
> the basic latic charset, larger for other locales).

Since the other sites will be doing things a bit differently, if we can include it on their behalf, I think that would be the more favorable option. We spend a bit of time already correcting bits of design and code that miss the brand toolkit. I could see the same happening with the tab, and it being a bit of a nuisance trying to keep everyone up to date. Less bugmail, more happy?

> 
> Can we expect jquery from the client site? Include it ourselves? Or work
> directly in Ye-Olde-Javascript to avoid the dependency?
> 

Same as above, working directly with ye-olde-javascript and avoiding the dependency will keep the tab's implementation across sites smoother.

> Should we use only CSS3 for the animation of the tab open/close, which would
> mean no animation (just instant open/close) in IE, or should we use jQuery
> animation? I would suggest we start with CSS3 and use jQuery animation as a
> fall-back.

+1. The best outcome would be to do this 100% with CSS3. It's also a great example of that technology in action.

> I'm sure we'll come up with some other issues as we get further into
> implementation. We haven't looked at pulling in about:home snippets into the
> promo area yet. I would suggest we start with something static and make that
> a post 1.0 feature.

+1. Agreed. For the initial rollout, we'll work with Matej on some type of "Welcome" messaging. Then iterate from there. Ideas on this are very welcome!

> While these elements (js/images/css) would likely be hosted on mozilla.org
> (and the associated CDN), we should treat the mozilla.org and
> mozilla.org/firefox sites as we would any other sites implementing the tab.

Yes. This should keep us pretty honest about the overall development of this web asset. It shouldn't be built to work on mozilla.org and /firefox and then fitted elsewhere, that's where I think we'll run into use cases we missed. 

Really appreciate the thoroughness of your inquiries, especially anticipating the issues that other websites might run into and how we can best avoid those and produce something that will have less bugs and more happy.
adding Potch to help with comment 28 and comment 29

Potch wrote over on onemozilla.org, 

"I think a great distribution mechanism would be for people to include the code in their website for the tab itself, and then a JS include to load all the content in onload. This would be a boon for performance and maintainability, as the content would be served from a central location (mozilla.org)."

Potch can you take a closer look at Steven's thoughts in comment 28 and some of my responses in comment 29 - you seem to be thinking about some of this stuff and we could use your insight here :-)
Whiteboard: r=100047
Whiteboard: r=100047 → r=100047, 100062 b=trunk
Steven/James -

If this is ready, let's roll it out to mozilla.org/firefox with next week's 1.3 release. One small content update, eliminate Betafarm from the Innovations section.

Steven,

mozilla.org does not currently use the grey tab, but this would be a great time to add it in there (if it can fit easily into the design) what do you think?
Assignee: smartell → steven
Target Milestone: 1.4 → 1.3
Whiteboard: r=100047, 100062 b=trunk → r=100047,100062,100067 b=trunk
James passing to you for implementation, I know 1.2 might be tight with SOPA, 1.3 would great!

Steven, thanks for all your work on this!
Assignee: steven → jlong
(In reply to mcbmoz from comment #32)
> James passing to you for implementation, I know 1.2 might be tight with
> SOPA, 1.3 would great!
> Steven, thanks for all your work on this!

To be clear, this isn't ready/finished yet. We've got a lot done, but still needs work.
Assignee: jlong → steven
This quick Firebug'ed mockup shows how the universal tab could work on the mozilla.org design. The mozilla.org design has a 30px vertical space between the top of the page and the start of the dark grey header bar. This really clashes with the tab. We could eliminate this space, as illustrated in this attached mockup. Thoughts?
(In reply to Steven Garrity from comment #34)
> Created attachment 589572 [details]
> Universal Tab on mozilla.org design
> 
> This quick Firebug'ed mockup shows how the universal tab could work on the
> mozilla.org design. The mozilla.org design has a 30px vertical space between
> the top of the page and the start of the dark grey header bar. This really
> clashes with the tab. We could eliminate this space, as illustrated in this
> attached mockup. Thoughts?

Simply stated. LOVE IT.
Depends on: 719563
Depends on: 720370
Depends on: 720458
Depends on: 720809
Steven, one small update to the content:

Add, "Support" under "Mozilla" and link to support.mozilla.com

Thank you!
(In reply to mcbmoz from comment #36)
> Steven, one small update to the content:
> 
> Add, "Support" under "Mozilla" and link to support.mozilla.com
> 
> Thank you!

Actually, please link to support.mozilla.org, to save a 301 - Moved Permanently redirect
(In reply to Stephen Donner [:stephend] from comment #37)
> (In reply to mcbmoz from comment #36)
> > Steven, one small update to the content:
> > 
> > Add, "Support" under "Mozilla" and link to support.mozilla.com
> > 
> > Thank you!
> 
> Actually, please link to support.mozilla.org, to save a 301 - Moved
> Permanently redirect

ah, that's right, thanks Stephen, we just did a global search and replace for that on the site.
Hello 

What about Thunderbird support? Where will we find the link to http://support.mozillamessaging.com/EN/home

AM
(In reply to mcbmoz from comment #36)
> Add, "Support" under "Mozilla" and link to support.mozilla.com

Added (with the .org tld): https://github.com/mozilla/tabzilla/commit/9ac4c0472d8acf792c78578b0422a78f44925978
(In reply to abourcier from comment #39)
> Hello 
> 
> What about Thunderbird support? Where will we find the link to
> http://support.mozillamessaging.com/EN/home
> 
> AM

Great question Anne Marie, Thunderbird Support will be discoverable in the following ways:

*support.mozilla.org will feature a link to Thunderbird Support (definitely follow up with David Tenser on those plans, which are outside of the scope for this bug)

*clicking on Thunderbird from the universal tab, which will take them to the Thunderbird landing page

*click on Firefox from the universal tab, which will take them to the Firefox landing page and from there it's in the sub-nav under Support

*search for Support in the search box

So, lots of entry points for users looking for Thunderbird Support.
Target Milestone: 1.3 → 1.4
Target Milestone: 1.4 → 1.5
Depends on: 723562
Depends on: 723565
As of r101065, tabzilla is actually working in trunk! It's on en-US pages only, and it needs some fixes in IE6 (coming up).
Whiteboard: r=100047,100062,100067 b=trunk → r=101065 b=trunk
IE stuff cleaned up. Let's get testin'!

Pages that should get particular attention from QA would be any that have a non-standard background color (dark aurora pages, the orange pages like /firefox/new/ and download, etc.)
Keywords: qawanted
Whiteboard: r=101065 b=trunk → r=101065,101070 b=trunk
Steven a few nits:

- should be "Developer Network", not "Developers Network"
- sometimes there is a little box around menu items (see attached)...would be good if we could remove that
- can Products link under Mozilla be Projects for now, since we're redoing that page, but it isn't ready yet. Otherwise it's confusing that we have a header and individual link called the same thing.
The issues from from comment #44 have all been addressed (might take a few minutes to update.
Let's get testing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: r=101065,101070 b=trunk → r=101065,101070, r101255, r101256 b=trunk
Whiteboard: r=101065,101070, r101255, r101256 b=trunk → r=101065,101070,101255,101256 b=trunk
pushed to production r101286
Depends on: 725273
Not really in the scope of this bug, but as of r101332 in trunk, the rest of the mozilla.org site now has tabzilla now too.
Why is Tabzilla loading stuff from ajax.googleapis.com? Do we have an existing privacy policy that covers the data being transmitted to that host?
(In reply to Reed Loden [:reed] (very busy) from comment #52)
> Why is Tabzilla loading stuff from ajax.googleapis.com? Do we have an
> existing privacy policy that covers the data being transmitted to that host?

Good question. Let's update this to load from our own CDN.
(In reply to Reed Loden [:reed] (very busy) from comment #52)
> Why is Tabzilla loading stuff from ajax.googleapis.com? Do we have an
> existing privacy policy that covers the data being transmitted to that host?

This is fixed in master - will be live soon-ish.
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: