[Design] Design team needs and Drupal site development

As Michael Wheatland posted on the website mailist, the Drupal site is
coming along quite well. We are just working on the Drupal site needs
for various groups.

I have created two threads: one for the [Marketing] team and one for
[Design] team to establish the needs for each group. Let us know on this
thread what your anticipated needs are and/or any wishes that you may
have to make your section work better. I will then update the Drupal
Website Development wiki page with your suggestions.
(http://wiki.documentfoundation.org/Website/Drupal/Marketing) with the data.

Try to be as complete as possible. We can still add more wishes later,
after the site goes live, but it will probably be busy with other
demands on the Drupal Website Devs.

Needed:  Please feel free to add any individual team requirements for
the final Drupal based website. All requirements should be non-specific.
ie. Instead of "a wiki to upload documents to" try "a web based document
control system". We care about detailed requirements here rather than
proposed solutions.

Your requirements
==================

* Ideas: (add any ideas that you may have; ideas that would allow better
work conditions for the design team etc.)

* File formats: (Should the Drupal team take into consideration any file
formats for your team? These are mostly for uploading/downloading
concerns.)

* Workflows / Procedures:


Cheers

Marc
Drupal Web. Dev. Team member


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On Thu, 2010-11-18 at 06:43 -0500, Marc Paré wrote:

> Your requirements
> ==================
>
> * Ideas: (add any ideas that you may have; ideas that would allow better
> work conditions for the design team etc.)

Starting from the needs of the Ubuntu Artwork team, a small group of us
have been thinking about a custom/standalone solution. My own thoughts
wandered towards a project-neutral design process and asset management
solution. So the input I have to offer here might be a bit much ;)

There are several aspects to this:
* The solution and the community around it should function a bit like a
design agency.
* It should work as a showcase of design done in an open, collaborative
fashion, by volunteers (and professionals)
* Design thinking and methods should be embedded in the infrastructure.
Combined with moderation/mentoring and successful, fully documented
projects as examples, this should turn the solution into a
teaching/learning environment.
* Neutrality of the platform should encourage participants to tackle
various projects and to share ideas and experiences across projects.


The underlying goal
===================

Foster quality and quantity of open design efforts and outcomes.

Definitions:

* Open design efforts: Design efforts that exhibit openness to the
public, collaboration, meritocracy, sharing and permissive licensing.

* Permissive Licenses: Licenses applicable to otherwise copyrighted
works that at least allow free redistribution and may also allow use for
any purpose, creating and distributing derivatives. Examples of
permissive license are the GPL and the Creative Commons family
(Non-Commercial and No_Derivatives variants are edge cases).


How?
====

* Offer a place to go for open design projects
* Increase the visibility of design efforts, outcomes and participants
* Make design more enjoyable, make it happen easier and faster
  * remove technical hurdles
  * shape social interactions in a positive manner
    * encourage feedback. silence hurts
    * encourage constructive criticism, discourage unspecific and
      unfounded criticism
    * encourage participators to pay attention to constructive criticism
    * avoid and protect against flaming, trolling and vandalism
  * apply automation
  * assist in managing various aspects of design projects
* Offer guidance and education to enable more, and more capable,
  participators
* take care of deployment/packaging/distribution


Mission
=======

Create, deploy and maintain a website for managing design processes and
assets.

Where assets are any kind of content wrapped in files such as images,
audio and video recordings or compound (text and images) documents.


The Why of Formal Design Processes
==================================

* Avoid oversights and typical errors by working step-by-step and using
checklists
* Increase width and depth of ideation and conception by working
methodically, including the use of patterns
* Avoid chaos by organizing thought, (inter)action and assets.


Social Issues to deal with
==========================

* laziness
* clique-building and power-trips
* unfounded like/dislike reactions
* non-constructive criticism
* flaming, trolling, vandalism
* not taking well to criticism


Roles
=====

* Visitor
* Seeker (needs or wants an asset)
* Requester (Owner, Client)
* Organizer (Facilitator, Steward, Coach, Mentor)
* Designer (Contributor)
* Watcher (provides feedback)


-------------------------------------------------------------------------


> * File formats: (Should the Drupal team take into consideration any file
> formats for your team? These are mostly for uploading/downloading
> concerns.)

PNG and SVG. With SVG it can be tricky to generate good
previews/thumbnails. At least if Inkscape has been used ;)


--------------------------------------------------------------------------


> * Workflows / Procedures:


Central Questions
=================

No matter if it is about visual design or interaction, central questions
are:
* What is the goal, or the problem at hand?
* Who brought it up or needs it solved?
* Who is, has been or is planning to work on it and in which role?
* What's the status/progress of the effort?
* What are the requirements?
* What needs to be researched / what is the outcome of said research
* What are the related assets
* What are the proposals to achieve the goal
...


Unit
====

I think the main unit of organization should be a (Design) Project. This
can be a representation of a large undertaking like LO itself, or a
specific task. Projects can contain other Projects.


Stages
======

A Project has a Initiation stage/part. Here we document the thoughts
that led to its creation in a loose format. Should be a case of write
once and rarely, if ever, touch again.

Central to almost everything that happens with a Project is the
Briefing. This is the formalized definition of what the Project is
about. Initially based on the Initiation, it may move away from it over
time. A description, checklist and examples should help.

Analysis: document what can be said about the problem/solution domain
based on critical thinking.

Research: Find out what you need to learn, do so, document it.

Requirements: Define them based on the above.

Conception/Drafting/Design: based on the complexity and needs of the
specific project, there may be one or several rounds of design proposals
from rough to refined.

Evaluation: might not appear as separate stage, but be integrated into
Conception/Drafting/Design.

Implementation (link to the work, track progress).

Deployment (planning, direct downloads in some cases).


Versioning
==========

Projects can be linear, but will have to be iterative in cases. For
example, what you learn in Research might make you change the Briefing
(you have to be sure you are solving the right problem).

(I'm not sure if the Initiation should be just the first version of the
Briefing, actually.)

So for every proposal and asset you need to know which version/iteration
of the Briefing it belongs to. Similar for all comments/discussion.

Work on assets like mockups should be version-managed, anyway.

Ideally there should be file-manager/file-system level integration, to
require neither commandline nor browser to pull/commit/push ...


Assets
======

Vector and raster images such as photos, drawings, diagrams and mockups.
Sound and video. Text and compound documents, perhaps.

Track:
* Creator
* Edits and Editors
* License
* Contains which other assets
* Is a derivative of which other asset
* Is used in
* Has been branched at and to

Allow branching. I would also mention merging, but that won't work in
many cases. There will likely have to be a pointer to the
main/official/trunk/head version.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Wow, Thorsten.
Now this is something we can work with. Tomorrow I will try to integrate
this into the wiki, and as I have some time free I will launch into
designing an artwork workflow and publication system that complies with your
requests.

Thank you very much for this very specific feedback, you will not
be disappointed with the outcome.

If anyone else has proposals like this, the Drupal website design team is
more than willing to bend over backwards to accommodate your requests. Keep
them coming

Michael Wheatland

--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On Thu, 2010-11-18 at 23:39 +0930, Michael Wheatland wrote:

> Now this is something we can work with. Tomorrow I will try to integrate
> this into the wiki, and as I have some time free I will launch into
> designing an artwork workflow and publication system that complies with your
> requests.

Awesome, thanks. Let me know if something needs to be cleared up, or if
you need design assistance. Otherwise just keep us informed about
progress, please ;)


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Hi Marc!

Although having some very experienced community members here, who are
able to come up with "requirements" that help to work on the web
infrastructure - let's quote one of the most famous people (in Germany)
working in the requirements development domain ... the term "users"
refers to us, the community, using the site.

"User's don't give requirements. They provide information".

If you ask for requirements, you might end up in getting answers that
lead to the same design like it is available today. Only few people
might come up with suggestions what might be better ... Thus, from the
"requirements engineering point-of-view", it might be better to (also)
ask for the usual tasks people do. Usually, this "cognitive
walk-through" enables people to state what they are comfortable with -
and what's less desired.

If I remember correctly, Thorsten already started to explain how graphic
requests and selection might work. I referred to the pages where we
collected ideas concerning "brainstorming" (the idea collection Michael
talked about in another thread). Maybe this can already be a starting
point ...

However, thanks for the structured approach. It already feels great to
see that!

Cheers,
Christoph


Am Donnerstag, den 18.11.2010, 06:43 -0500 schrieb Marc Paré:
> Needed:  Please feel free to add any individual team requirements for
> the final Drupal based website. All requirements should be
> non-specific.
> ie. Instead of "a wiki to upload documents to" try "a web based
> document
> control system". We care about detailed requirements here rather than
> proposed solutions.


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Le 2010-11-19 04:36, Thorsten Wilms a écrit :
Hi Thorsten and Michael

I have referenced the proposal here the "Marketing Drupal Website
Requirements" page here:
http://wiki.documentfoundation.org/Website/Drupal/Marketing

Cheers

Marc


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Le 2010-11-19 04:36, Thorsten Wilms a écrit :


To clarify
Is there a proposed marketing team structure?

ie.
Marketing
 - Branding
     -Logo
 - Design (Artwork)
 - Promotions
 - etc

If so I would love to get my hands on it for the Drupal site development.

Also it would be good to put this structure or a representation of the
structure on the wiki marketing page:
http://wiki.documentfoundation.org/Marketing

Michael Wheatland

--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On Fri, 2010-11-19 at 12:19 +0100, Christoph Noack wrote:

> "User's don't give requirements. They provide information".
>
> If you ask for requirements, you might end up in getting answers that
> lead to the same design like it is available today. Only few people
> might come up with suggestions what might be better ...

It's true that if you ask users for requirements, the answers will often
be based on existing solutions and lots of hidden assumptions.

I'm in 2 roles here, designer and potential user. You could assume a
risk of what I offer being to too self-centered. On the other hand I
have the domain-specific knowledge and experience that is needed. The
fun thing is that I have to apply it on itself ;)

Also note that much of what I wrote is not about what people have been
or are doing, but is about what they should be doing.

You really don't need to worry about this leading to a design like it
would be available today, already. I'm rather sure there is no
open-source solution, yet. I'm not familiar with proprietary solutions
that might exist, so no risk of blindly copying them.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On Sat, 2010-11-20 at 13:44 +0930, Michael Wheatland wrote:

I'm not aware of such a proposal.

I would never place Design below Marketing (or Engineering or whatever
else). Design done right touches the Why, What and How of a
product/project/system. It permeates everything.

The term Artwork might seem handy to label stuff to just look at, no
interaction. But it may suggest an "intuitive", subjective "just do it"
approach, in contrast to the planning and evaluation that belongs to
design.


As we need some separation, I would say design has to happen on 5
levels:
* Core: planning/steering/governance for the entire LO project
* Interface/Interaction design within the office suite
* Interface/Interaction design for the website(s)
* Communication/Visual design for documentation
* Communication/Visual design for marketing purposes


* Core: planning/steering/governance for the entire LO project
has to happen centrally and nobody would expect to see a "design" label
attached.


The planned Design mailing list should include:
* Interface/Interaction design within the office suite
and may also cover:
* Interface/Interaction design for the website(s)
* Communication/Visual design for documentation
* Communication/Visual design for marketing purposes

But
* Communication/Visual design for marketing purposes
is a topic for the marketing list.
* Interface/Interaction design for the website(s)
is a topic for a website list (if we have one).
* Communication/Visual design for documentation
is a topic for a documentation list (if we have one).


I would appreciate if we could switch to a terminology where Brand and
Branding are about the outcome, the perception. What you actively work
on is the (Corporate or Visual) Identity.


Marketing may include:
* Message/communication design
* Strategy/positioning (maybe not separable from the first)
* Visual design of marketing material
* Planning, executing and tracking marketing activities


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Thanks for the well thought out structure proposal Thorsten. (This
statement does not say that I agree with your proposal.)

The Marketing Team does not as yet have such a structure. We have just
only recently adopted the "Design" level, but I believe in our present
structure that the Design level was thought of at the same level of
importance as "Marketing".

This thread was meant to really get details of the present structure for
the [Design] level. I had broken it up into 2 sections as we had just
recently spoken of separating the Design level from the Marketing
level.Thus the reason for the two threads:

[Design] Design team needs and Drupal site development
[Marketing] Marketing team needs and Drupal site development

In fact this is probably the best time to discuss/debate structure as it
will fit in well with the Drupal Web Dev. Team push to get a clearer
picture of the different structures in groups such as the Marketing;
Communications and Dev. We are just paving the way towards the migration
to the Drupal site and need this information to build each Drupal site.

Marc


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

I'll try to put some information that I think is pertinent and perhaps
members will chime in and add other information of their own.

The information needed is not for data but merely to help in
establishing the structure; file format considerations etc. so that when
the migration from the Silverstripe to the Drupal in early 2011 is done
with the least amount of disruptions and as seamlessly as possible. We
are not talking about data.

For example, from my own perspective, the [Design Team] needs:

* Ideas: area where team members can chat in public as well as a private
area; public and private mailist; white board area to comment on design
graphs or to rough sketch live for examples ... collaborative if
possible (where other members can contribute live to a design sketch); a
repository for artwork; perhaps voting capabilities for when members are
asked to choose a "winning" design ... along with the capability to
comment, some type of reference area where colour palettes are stored as
well as design guidelines, FAQ section

* File formats: .png, tif, .jpg, raw, svg, Photoshop formats, all
openoffice formats, MSO formats

* Workflows / Procedures: work in progress


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On 11/20/2010 07:58 PM, Marc Paré wrote:

> * Ideas: area where team members can chat in public as well as a private
> area; public and private mailist; white board area to comment on design
> graphs or to rough sketch live for examples ... collaborative if
> possible (where other members can contribute live to a design sketch); a
> repository for artwork; perhaps voting capabilities for when members are
> asked to choose a "winning" design ... along with the capability to
> comment, some type of reference area where colour palettes are stored as
> well as design guidelines, FAQ section

I think that work in progress should not be on the web site but on the
wiki (white board areas, collaborative areas), while reference docs can
be on the web site (colour palettes, design guidelines, FAQ sections).

> * File formats: .png, tif, .jpg, raw, svg, Photoshop formats, all
> openoffice formats, MSO formats

PDF is mandatory, together with all standard documents formats, while I
would avoid proprietary formats like PSD (PhotoShop).

> * Workflows / Procedures: work in progress

Again, work in progress should be on the wiki.

The web site cannot contain work in progress, as it should be the basic
source of information about TDF and LibreOffice, and people are usually
quoting from the web site without double checking. The presence of work
in progress on the web site is too risky, and I am totally against it.

--
Italo Vignoli - The Document Foundation
E-mail: [hidden email]
Mobile +39.348.5653829 - VoIP: +39.02.320621813
Skype: italovignoli - GTalk: [hidden email]

--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Thanks Italo:

Le 2010-11-20 14:30, Italo Vignoli a écrit :
Agreed

>> * File formats: .png, tif, .jpg, raw, svg, Photoshop formats, all
>> openoffice formats, MSO formats
>
> PDF is mandatory, together with all standard documents formats, while I
> would avoid proprietary formats like PSD (PhotoShop).

Have you ever had an artwork contributor send a photoshop file for the
team to look at? If so, the Drupal site Team Devs will test the site to
make sure that there are no hiccups if this is ever done. The list is
not to support any of the files formats but to allow the Drupal Team
Devs the change to test to see if there would be any problems on the
site if there was any kind of exchange.

>
>> * Workflows / Procedures: work in progress

The "Work in progress" will not appear on the website nor will the
Drupal Web Devs put it on the wiki. This thread is only for our internal
check list to make sure that we have covered as much as possible as far
as organising this section of the site so that the transitions runs
smoothly.

>
> Again, work in progress should be on the wiki.
>
> The web site cannot contain work in progress, as it should be the basic
> source of information about TDF and LibreOffice, and people are usually
> quoting from the web site without double checking. The presence of work
> in progress on the web site is too risky, and I am totally against it.
>

Completely in agreement. I would also object to such information that
would make the team look disorganised.

Thanks for the info. Just write in if you think that there are other
aspects that we should check or if we should ready anything else for the
Design site on the Drupal LibO website. Once we have organised the site
we will ask for people to test it and for comments.

Marc


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On Sat, 2010-11-20 at 20:30 +0100, Italo Vignoli wrote:
Hi Italo,

I fully agree with the sentiment, but disagree with your take on the
ability of the platform in question.

The wiki is a tool and one that only hides details from the general
public by obscurity (well, without a fair bit of re-configuration
anyway).

A CMS on the other hand allows the website to be constructed in such a
way that different content goes to different types of users - so a
non-registered user could easily be kept from seeing any work in
progress. while works in progress that need to be available to the
community members are so, and even then can be controlled as to who sees
what, and what they can do with it.

So of course the wiki is a tool that is going be used, but the process
of design, as is ongoing here, and then implementation via a CMS, such
as Drupal or Silverstripe for that matter, is precisely a mechanism for
delivery of a system that performs in the way you describe, IMO.

Thanks

Drew


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On 11/20/2010 09:04 PM, drew wrote:

> So of course the wiki is a tool that is going be used, but the process
> of design, as is ongoing here, and then implementation via a CMS, such
> as Drupal or Silverstripe for that matter, is precisely a mechanism for
> delivery of a system that performs in the way you describe, IMO.

I do not mind about the platform. I know that when the information is on
the web site it is considered official, while the same information on a
wiki is not official (I can ask the press to amend a statement taken
from the wiki, but I cannot ask to amend a statement taken from the web
site). I assume that information visible on the web site are officially
approved documents, while you can easily write on a wiki page that "this
is work in progress, and should not be considered officially approved".

I do not mind what happens before the publication on the web site. I am
not concerned of what happens behind the scenes, also because I am not a
tech guy and most of the times I do not understand technology.

--
Italo Vignoli - The Document Foundation
E-mail: [hidden email]
Mobile +39.348.5653829 - VoIP: +39.02.320621813
Skype: italovignoli - GTalk: [hidden email]

--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On 11/20/2010 08:46 PM, Marc Paré wrote:

> Have you ever had an artwork contributor send a photoshop file for the
> team to look at? If so, the Drupal site Team Devs will test the site to
> make sure that there are no hiccups if this is ever done. The list is
> not to support any of the files formats but to allow the Drupal Team
> Devs the change to test to see if there would be any problems on the
> site if there was any kind of exchange.

I am referring to what is published on the web site. I do not want to
enter into technical details about the web site development and the
tools used, as I am not qualified for technical discussions.

--
Italo Vignoli
[hidden email]
Mobile +39.348.5653829
VoIP: +39.02.320621813
Skype: italovignoli

--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Le 2010-11-20 16:22, Italo Vignoli a écrit :
Thanks Italo.

Marc


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

Le 2010-11-20 16:20, Italo Vignoli a écrit :
Some of these tools can be integrated on the site. For example, the wiki
pages could be used through the site. So when you log in, you could be
given the permission to work on a public wiki with the right to modify
the pages just as you do now. You could also be given permission to work
on a private members only wiki where only designated members are allowed
to work and see the information -- the pages would be hidden from public
view.

The website does not need to be the final resting place for official
documents; it can also be the place where people do all of their prep
work and discussion as well as emailing or white boarding.

This is what the Silverstripe and Drupal sites are all about. A one stop
shop place where everything is available under one roof but also where
all is built according to permissions to users as to what levels of the
website they may work on or see.

Marc


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

On Sat, 2010-11-20 at 22:20 +0100, Italo Vignoli wrote:
> I do not mind what happens before the publication on the web site

Right - and that is the key descriptor, publication.

Your speaking as if there is only one view of the web site, there is not
when under the control of a CMS system. There is a view that is
published, official in other words

There can be completely different features of the site visible only to
those with valid credentials.

Unless you are really concerned with the idea that there would be a lack
of discipline in the site admin or user actions, such that some work
item ends up visible at the official view.

Also, there two sites TDF and LibO, isn't much of what you would be
concerned with, as far as this official communication channel makes most
sense at the TDF site?

In some previous emails I've tried to argue the LibO site be about users
and TDF about workers, but this is a good reason to rethink that opinion
it seems. Perhaps it is appropriate rather to think of the LibO domain
for the main work site, along with user support (distro, etc) and think
of the TDF site as more of an official communication organ.

Curious of your thoughts are on this.

Thanks

Drew


--
E-mail to [hidden email] for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted

I found it very hard to follow this conversation. Can we take a step back.
The marketing list should not be the place for discussing website
infrastructure.

Quote of Initial email
>Needed:  Please feel free to add any individual team requirements for the
final Drupal based website. All requirements should be non-specific. ie.
Instead of "a wiki to upload documents to" try "a web based document control
system". We care about detailed requirements here rather than proposed
solutions.

Thorsten's email reply was greatly detailed and something we can work off.
Again. If you have a requirement, such as 'Draft work being private' please
let us know about the requirements for a task, not the infrastructure that
drives it.
If anybody wishes to get more involved with the discussion about the
infrastructure, can I suggest subscribing to the website mailing list.

Michael Wheatland

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://www.libreoffice.org/lists/marketing/
*** All posts to this list are publicly archived for eternity ***