7:59 p.m.
Hi,
Not sure this is the right list...
I think that there is a gap from what user(and developer) expects to see in open source
(or any) site and what we have.
We are missing "Support" category, there we should have the user lists and a
link to bugzilla, and some bugzilla links for reports (opened bugs for example).
We are missing "Source" category, a clear place of how to obtain the source, as
we do not have proper gitweb with list of projects, at least link to
http://gerrit.ovirt.org/#/admin/projects/.
Community is not a proper word for "Mailing lists", first thing I look is for
"list" in the home page and I expect it to be there, the term "Have
conversations on our mailing lists" is not something common although it may be good
English.
At http://www.ovirt.org/Mailing_lists, I expect the term "Full index of mailing
list" instead of "the oVirt mailman page".
In the "the oVirt mailman page" we are missing vdsm lists.
Regards,
Alon
9:01 p.m.
Quoting Alon Bar-Lev <alonbl(a)redhat.com>:
Hi,
Not sure this is the right list...
I think that there is a gap from what user(and developer) expects to
see in open source (or any) site and what we have.
We are missing "Support" category, there we should have the user
lists and a link to bugzilla, and some bugzilla links for reports
(opened bugs for example).
I agree. It is assumed that a new contributor comes with an
agenda/idea of what he/she wants implemented in ovirt. There is no
place for someone new or experienced to see what needs to be done.
Some of the bugs have access control and are not visible to the
community. We should have something like kernel janitor.
I can speak to it with some authority since I am not from the
core/original ovirt team.
Regards
Sharad Mishra
We are missing "Source" category, a clear place of how to obtain the
source, as we do not have proper gitweb with list of projects, at
least link to http://gerrit.ovirt.org/#/admin/projects/.
Community is not a proper word for "Mailing lists", first thing I
look is for "list" in the home page and I expect it to be there, the
term "Have conversations on our mailing lists" is not something
common although it may be good English.
At http://www.ovirt.org/Mailing_lists, I expect the term "Full index
of mailing list" instead of "the oVirt mailman page".
In the "the oVirt mailman page" we are missing vdsm lists.
Regards,
Alon
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
9:53 a.m.
Hi Alon,
On 12/18/2012 07:59 PM, Alon Bar-Lev wrote:
Not sure this is the right list...
It will do to begin :-) We had design discussions on arch@ before, and
implementation decisions here.
I think that there is a gap from what user(and developer) expects to
see in open source (or any) site and what we have.
We are missing "Support" category, there we should have the user lists and a
link to bugzilla, and some bugzilla links for reports (opened bugs for example).
My thinking re "Support" is that it could be a good addition - currently
"Documentation" and "Community" answer the use-case "Help!
I'm stuck" -
plus, of course, the integrated search box. My only concern is that we
already have 6 top-level menu items, and adding another one would make
things worse from a usability point of view. Perhaps "Support" could
replace one of the other top-level menu items - but which one?
We are missing "Source" category, a clear place of how to
obtain the source, as we do not have proper gitweb with list of projects, at least link to
http://gerrit.ovirt.org/#/admin/projects/.
On "Source" I don't really think it is a top-level menu item. There is a
much better argument for "Support" or "Get help".
There is a general ergonomics rule of thumb that top-level categories
should not be more than 5 or 6, and not be fewer than 3 or 4 - even 6 is
giving the user a lot of choice and a lot of things to read, and if you
only have 2 items, you're better off avoiding a header altogether and
designing your page around those 2 categories. So I'm happy having "Get
the source code" under "Develop" and under "Download".
We don't have a good page on getting the source code right now - the
process is different for Node, Engine, VDSM, etc. This might be a good
community project for someone.
Community is not a proper word for "Mailing lists", first
thing I look is for "list" in the home page and I expect it to be there, the
term "Have conversations on our mailing lists" is not something common although
it may be good English.
At http://www.ovirt.org/Mailing_lists, I expect the term "Full index of mailing
list" instead of "the oVirt mailman page".
In the "the oVirt mailman page" we are missing vdsm lists.
On the location of the mailing lists: The Community page could perhaps
be improved. There is a lot of text right now, and we can definitely
improve on it and make the actions available much more prominent.
Suggestions are welcome!
On the VDSM mailing lists being missing from the oVirt mailman page,
this is a consequence of the list being hosted on fedorahosted -
suggested improvements to the text are appreciated.
Thanks for the feedback, Alon!
Cheers,
Dave.
--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
2:46 p.m.
----- Original Message -----
From: "Dave Neary" <dneary(a)redhat.com>
To: infra(a)ovirt.org
Sent: Wednesday, December 19, 2012 10:53:04 AM
Subject: Re: oVirt site organization
Hi Alon,
On 12/18/2012 07:59 PM, Alon Bar-Lev wrote:
> Not sure this is the right list...
It will do to begin :-) We had design discussions on arch@ before,
and
implementation decisions here.
> I think that there is a gap from what user(and developer) expects
> to see in open source (or any) site and what we have.
>
> We are missing "Support" category, there we should have the user
> lists and a link to bugzilla, and some bugzilla links for reports
> (opened bugs for example).
My thinking re "Support" is that it could be a good addition -
currently
"Documentation" and "Community" answer the use-case "Help!
I'm stuck"
-
plus, of course, the integrated search box. My only concern is that
we
already have 6 top-level menu items, and adding another one would
make
things worse from a usability point of view. Perhaps "Support" could
replace one of the other top-level menu items - but which one?
Support is a must, people look for this word.
Drop the community, as it has no sense, the whole ovirt is a community.
Open source project has usually several top most goals:
1. license - IMPORTANT artifact, it is one of the first things people are looking in open
source project.
2. support - IMPORTANT artifact, mailing lists, bugzilla.
3. source - IMPORTANT artifacts, this is open source project, the source is the center of
all activity.
> We are missing "Source" category, a clear place of how to obtain
> the source, as we do not have proper gitweb with list of projects,
> at least link to http://gerrit.ovirt.org/#/admin/projects/.
On "Source" I don't really think it is a top-level menu item. There
is a
much better argument for "Support" or "Get help".
People should have immediate path to access the source in open source project, this is
what it is about.
There is a general ergonomics rule of thumb that top-level
categories
should not be more than 5 or 6, and not be fewer than 3 or 4 - even 6
is
giving the user a lot of choice and a lot of things to read, and if
you
only have 2 items, you're better off avoiding a header altogether and
designing your page around those 2 categories. So I'm happy having
"Get
the source code" under "Develop" and under "Download".
I don't approve these ergonomics rules... If these rules makes the site unusable for
me as a new comer, and I cannot find what I look for (which I do find in other similar
sites), then something is wrong with these rules.
We don't have a good page on getting the source code right now -
the
process is different for Node, Engine, VDSM, etc. This might be a
good
community project for someone.
It is master site design... not a separate project.
> Community is not a proper word for "Mailing lists",
first thing I
> look is for "list" in the home page and I expect it to be there,
> the term "Have conversations on our mailing lists" is not
> something common although it may be good English.
>
> At http://www.ovirt.org/Mailing_lists, I expect the term "Full
> index of mailing list" instead of "the oVirt mailman page".
>
> In the "the oVirt mailman page" we are missing vdsm lists.
On the location of the mailing lists: The Community page could
perhaps
be improved. There is a lot of text right now, and we can definitely
improve on it and make the actions available much more prominent.
Suggestions are welcome!
On the VDSM mailing lists being missing from the oVirt mailman page,
this is a consequence of the list being hosted on fedorahosted -
suggested improvements to the text are appreciated.
All source repositories and mailing list of ovirt should appear in ovirt.org.
This includes all related projects without exception.
Thanks,
Alon.
8:18 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig258F56716B86D22986221A3D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 12/19/2012 05:46 AM, Alon Bar-Lev wrote:
=20
=20
----- Original Message -----
> From: "Dave Neary" <dneary(a)redhat.com> To: infra(a)ovirt.org Sent:
> Wednesday, December 19, 2012 10:53:04 AM Subject: Re: oVirt site
> organization
>=20
> Hi Alon,
>=20
> On 12/18/2012 07:59 PM, Alon Bar-Lev wrote:
>> Not sure this is the right list...
>=20
> It will do to begin :-) We had design discussions on arch@ before,=20
> and implementation decisions here.
>=20
>> I think that there is a gap from what user(and developer)
>> expects to see in open source (or any) site and what we have.
>>=20
>> We are missing "Support" category, there we should have the user=20
>> lists and a link to bugzilla, and some bugzilla links for
>> reports (opened bugs for example).
>=20
> My thinking re "Support" is that it could be a good addition -=20
> currently "Documentation" and "Community" answer the use-case
> "Help! I'm stuck" - plus, of course, the integrated search box. My
> only concern is that we already have 6 top-level menu items, and
> adding another one would make things worse from a usability point
> of view. Perhaps "Support" could replace one of the other top-level
> menu items - but which one?
=20
Support is a must, people look for this word. Drop the community, as
it has no sense, the whole ovirt is a community.
There is definitely evidence that "Community" - and all the content we
currently have on the [[Community]] page - are something people look for
when they come to an open source project.
Open source project has usually several top most goals:
=20
1. license - IMPORTANT artifact, it is one of the first things people
are looking in open source project.
=20
2. support - IMPORTANT artifact, mailing lists, bugzilla.
=20
3. source - IMPORTANT artifacts, this is open source project, the
source is the center of all activity.
The source is the center of developer activity. These days, people don't
prefer to compile a project from source. That is why [[Download]] is ther=
e.
Is there any reason we can't just put "How to obtain source" under the
[[Download]] page?
If I go to a project and see "Source" as a top-level menu item, I'm not
sure if this project is for me - does this mean I have to compile from
source? *ick* Does this mean the project is all about the source code,
and my expertise as an infrastructure or documentation guru isn't welcome=
?
Users and contributors of all types are the target audience for that
page. Source is of interest to only a subset of those groups, and scary
to another subset.
For those reasons, I'm not sure "Source" is a good idea for a top-level
menu item. Especially since I agree that we want to limit the amount of
menu items for UX reasons.
>=20
>> We are missing "Source" category, a clear place of how to obtain=20
>> the source, as we do not have proper gitweb with list of
>> projects, at least link to
>> http://gerrit.ovirt.org/#/admin/projects/.
>=20
> On "Source" I don't really think it is a top-level menu item.
> There is a much better argument for "Support" or "Get help".
=20
People should have immediate path to access the source in open source
project, this is what it is about.
=20
> There is a general ergonomics rule of thumb that top-level
> categories should not be more than 5 or 6, and not be fewer than 3
> or 4 - even 6 is giving the user a lot of choice and a lot of
> things to read, and if you only have 2 items, you're better off
> avoiding a header altogether and designing your page around those 2
> categories. So I'm happy having "Get the source code" under
> "Develop" and under "Download".
=20
I don't approve these ergonomics rules... If these rules makes the
site unusable for me as a new comer, and I cannot find what I look
for (which I do find in other similar sites), then something is wrong
with these rules.
Personally, I don't understand intuitively all the user experience and
interface decisions that expert designers make. I recommend, though,
that we don't dismiss them outright without trying to understand and
consider the various consequences. On that front, Garrett will be back
in the new year, and I'm sure is happy to help our understanding.
Bottom line for me is, too many links on a page is not what I'm looking
for. Well organized information where I can find what I want without
having to use Search, that's what I want.
It's OK that others don't mind too many links. But others definitely
*do* mind too many links and walk away when a wall of links is presented
to them. What's the right # of links for a top-nav or for a page? That's
debatable, but there has to be some guidance and rule, or we end up
looking list this:
http://web.archive.org/web/20020525101346/http://www.netscape.com/
> We don't have a good page on getting the source code right
now -
> the process is different for Node, Engine, VDSM, etc. This might be
> a good community project for someone.
=20
It is master site design... not a separate project.
I think Dave simply means, that page is a wiki page, anyone can edit,
and it would be a good task for someone to improve that page.
>> Community is not a proper word for "Mailing lists",
first thing
>> I look is for "list" in the home page and I expect it to be
>> there, the term "Have conversations on our mailing lists" is not=20
>> something common although it may be good English.
>>=20
>> At http://www.ovirt.org/Mailing_lists, I expect the term "Full=20
>> index of mailing list" instead of "the oVirt mailman page".
>>=20
>> In the "the oVirt mailman page" we are missing vdsm lists.
>=20
>=20
> On the location of the mailing lists: The Community page could=20
> perhaps be improved. There is a lot of text right now, and we can
> definitely improve on it and make the actions available much more
> prominent. Suggestions are welcome!
>=20
> On the VDSM mailing lists being missing from the oVirt mailman
> page, this is a consequence of the list being hosted on
> fedorahosted - suggested improvements to the text are appreciated.
=20
All source repositories and mailing list of ovirt should appear in
ovirt.org. This includes all related projects without exception.
This is simply a mistaken link on a wiki page. It should go to the
fedorahosted.org mailing list, and I just fixed it to go there.
What is really missing is the [[VDSM]] page on the wiki. Cf.:
http://ovirt.org/Engine
http://ovirt.org/Node
http://ovirt.org/VDSM <=3D=3D missing
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enig258F56716B86D22986221A3D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iD8DBQFQ0hLr2ZIOBq0ODEERAmPOAJwPZrjES0rzbU6PdqaYX/AZBy8FGQCdGM3y
SiToJKOfRvEV2/qXL9iATnA=
=rlBx
-----END PGP SIGNATURE-----
--------------enig258F56716B86D22986221A3D--
8:53 p.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: infra(a)ovirt.org
Sent: Wednesday, December 19, 2012 9:18:03 PM
Subject: Re: oVirt site organization
On 12/19/2012 05:46 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Dave Neary" <dneary(a)redhat.com> To: infra(a)ovirt.org
Sent:
>> Wednesday, December 19, 2012 10:53:04 AM Subject: Re: oVirt site
>> organization
>>
>> Hi Alon,
>>
>> On 12/18/2012 07:59 PM, Alon Bar-Lev wrote:
>>> Not sure this is the right list...
>>
>> It will do to begin :-) We had design discussions on arch@ before,
>> and implementation decisions here.
>>
>>> I think that there is a gap from what user(and developer)
>>> expects to see in open source (or any) site and what we have.
>>>
>>> We are missing "Support" category, there we should have the user
>>> lists and a link to bugzilla, and some bugzilla links for
>>> reports (opened bugs for example).
>>
>> My thinking re "Support" is that it could be a good addition -
>> currently "Documentation" and "Community" answer the
use-case
>> "Help! I'm stuck" - plus, of course, the integrated search box.
My
>> only concern is that we already have 6 top-level menu items, and
>> adding another one would make things worse from a usability point
>> of view. Perhaps "Support" could replace one of the other
>> top-level
>> menu items - but which one?
>
> Support is a must, people look for this word. Drop the community,
> as
> it has no sense, the whole ovirt is a community.
There is definitely evidence that "Community" - and all the content
we
currently have on the [[Community]] page - are something people look
for
when they come to an open source project.
I am very sorry, but I strongly disagree.
I would consider that the [[Community]] is pressed because of lack of better options...
> Open source project has usually several top most goals:
>
> 1. license - IMPORTANT artifact, it is one of the first things
> people
> are looking in open source project.
>
> 2. support - IMPORTANT artifact, mailing lists, bugzilla.
>
> 3. source - IMPORTANT artifacts, this is open source project, the
> source is the center of all activity.
The source is the center of developer activity. These days, people
don't
prefer to compile a project from source. That is why [[Download]] is
there.
Is there any reason we can't just put "How to obtain source" under
the
[[Download]] page?
Because it is not download, sorry, it is entirely different.
At download you download RELEASE.
At source you get access to the SOURCE CONTROL.
Two different audiences, two different artifacts.
You can put a clear title under the MAIN page of develop, with a clear list (maybe auto
generated) of all git repositories we have. It should not be hidden at 3rd level page
under unclear title of "subprojects".
If I go to a project and see "Source" as a top-level menu
item, I'm
not
sure if this project is for me - does this mean I have to compile
from
source? *ick* Does this mean the project is all about the source
code,
and my expertise as an infrastructure or documentation guru isn't
welcome?
I strongly disagree. If you have "Download" you go to download if you want to
download, if you have "Support" you go to support to get support, the existence
of "Source" or "Develop" which are the same is no way tells anything
for you inexperience user.
Users and contributors of all types are the target audience for that
page. Source is of interest to only a subset of those groups, and
scary
to another subset.
I suggest taking ideas from the following sites:
http://www.libreoffice.org/
http://www.openoffice.org/
http://kde.org/
http://xfce.org/
http://www.cacti.net/
For those reasons, I'm not sure "Source" is a good idea
for a
top-level
menu item. Especially since I agree that we want to limit the amount
of
menu items for UX reasons.
>>
>>> We are missing "Source" category, a clear place of how to obtain
>>> the source, as we do not have proper gitweb with list of
>>> projects, at least link to
>>> http://gerrit.ovirt.org/#/admin/projects/.
>>
>> On "Source" I don't really think it is a top-level menu item.
>> There is a much better argument for "Support" or "Get
help".
>
> People should have immediate path to access the source in open
> source
> project, this is what it is about.
>
>> There is a general ergonomics rule of thumb that top-level
>> categories should not be more than 5 or 6, and not be fewer than 3
>> or 4 - even 6 is giving the user a lot of choice and a lot of
>> things to read, and if you only have 2 items, you're better off
>> avoiding a header altogether and designing your page around those
>> 2
>> categories. So I'm happy having "Get the source code" under
>> "Develop" and under "Download".
>
> I don't approve these ergonomics rules... If these rules makes the
> site unusable for me as a new comer, and I cannot find what I look
> for (which I do find in other similar sites), then something is
> wrong
> with these rules.
Personally, I don't understand intuitively all the user experience
and
interface decisions that expert designers make. I recommend, though,
that we don't dismiss them outright without trying to understand and
consider the various consequences. On that front, Garrett will be
back
in the new year, and I'm sure is happy to help our understanding.
Bottom line for me is, too many links on a page is not what I'm
looking
for. Well organized information where I can find what I want without
having to use Search, that's what I want.
It's OK that others don't mind too many links. But others definitely
*do* mind too many links and walk away when a wall of links is
presented
to them. What's the right # of links for a top-nav or for a page?
That's
debatable, but there has to be some guidance and rule, or we end up
looking list this:
http://web.archive.org/web/20020525101346/http://www.netscape.com/
>> We don't have a good page on getting the source code right now -
>> the process is different for Node, Engine, VDSM, etc. This might
>> be
>> a good community project for someone.
>
> It is master site design... not a separate project.
I think Dave simply means, that page is a wiki page, anyone can edit,
and it would be a good task for someone to improve that page.
We should generate this page, there is no sense in maintaining it by hand.
>>> Community is not a proper word for "Mailing lists", first thing
>>> I look is for "list" in the home page and I expect it to be
>>> there, the term "Have conversations on our mailing lists" is not
>>> something common although it may be good English.
>>>
>>> At http://www.ovirt.org/Mailing_lists, I expect the term "Full
>>> index of mailing list" instead of "the oVirt mailman page".
>>>
>>> In the "the oVirt mailman page" we are missing vdsm lists.
>>
>>
>> On the location of the mailing lists: The Community page could
>> perhaps be improved. There is a lot of text right now, and we can
>> definitely improve on it and make the actions available much more
>> prominent. Suggestions are welcome!
>>
>> On the VDSM mailing lists being missing from the oVirt mailman
>> page, this is a consequence of the list being hosted on
>> fedorahosted - suggested improvements to the text are appreciated.
>
> All source repositories and mailing list of ovirt should appear in
> ovirt.org. This includes all related projects without exception.
This is simply a mistaken link on a wiki page. It should go to the
fedorahosted.org mailing list, and I just fixed it to go there.
What is really missing is the [[VDSM]] page on the wiki. Cf.:
http://ovirt.org/Engine
http://ovirt.org/Node
http://ovirt.org/VDSM <== missing
Thanks, however I am almost sure the list at[1] is incomplete.
It is *VERY* confusing to read:
"There are many mailing lists in the oVirt project - mostly referenced on the oVirt
mailman page"
Then see that mailman page does not contain one of the most important list - vdsm.
And what is mostly? where are the other?
Instead of worrying at this point how much top menu item do we have, I think we need to
get into better shape first.
As current state for people of type *ME* smells like immature project.
So let's summary my point of view.
COMMUNITY
news and events.
DOWNLOAD
download source, download distribution specific packages.
Download page should have SOURCE title and BINARIES title.
Under SOURCE there should be a link to WebDAV of sources (ALL VERSIONS).
Under BINARIES title there should be FEDORA, under FEDORA should be FEDORA 17, under
FEDORA 17 there should be repository settings for each version and link to WebDAV of RPMs
(ALL VERSIONS).
etc...
DOCUMENTATION
Should be user documentation.
I don't think developers are looking for developers documentation at top level
documentation.
SUPPORT
A reference to all mailing list.
A reference to bugzilla.
A reference to IRC.
A reference to HOWTOs and FAQ at wiki.
DEVELOP
"Access the source" -> cgit/gitweb front-end with all source repositories.
"Developer documentation"
Development (entry level) mailing list
Action items:
move vdsm lists to ovirt.org.
Thanks,
Alon
[1] http://www.ovirt.org/Mailing_lists
- Karsten
--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
8:03 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9DE54E094924A08CCE7DD064
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 12/19/2012 12:53 AM, Dave Neary wrote:
=20
My thinking re "Support" is that it could be a good addition - currentl=
y
"Documentation" and "Community" answer the
use-case "Help! I'm stuck" -=
plus, of course, the integrated search box. My only concern is that
we
already have 6 top-level menu items, and adding another one would make
things worse from a usability point of view. Perhaps "Support" could
replace one of the other top-level menu items - but which one?
How about both? We could put Docs under Support, clearly. But we could
also put "community support" under Support.
Hmm, not to sure about that, though ... there are a lot of things on the
Community page that are things people look for that don't belong elsewher=
e.
I do think people will look for documentation on the Support page.
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enig9DE54E094924A08CCE7DD064
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iD8DBQFQ0g992ZIOBq0ODEERAt6DAJ4//jRdn2o7q9xew38/NAY5CsZcpgCeJcub
eTaKAEQiHHFGVUxUgZOcMDU=
=nCgS
-----END PGP SIGNATURE-----
--------------enig9DE54E094924A08CCE7DD064--
4139
days inactive
4140
days old
6 comments
4 participants
participants (4)
-
Alon Bar-Lev -
Dave Neary -
Karsten 'quaid' Wade -
snmishra＠linux.vnet.ibm.com