A visitor can browse case studies.

cedewey commented

2018-01-24 21:42:53 +00:00

(Migrated from gitlab.com)

Acceptance Criteria

Given that I am a visitor
when I visit /work
then I see a list of case study teasers.

Links

Work Required

Create view
Add "Our Work" title
Customize views template
- Add "is-2" class to page title
- Add div around all tiles with classes "columns is-multiline"
- Add div around each tile with class "column is-one-third"
Package into Case Study feature

## Acceptance Criteria Given that I am a visitor when I visit /work then I see a list of case study teasers. ## Links * [View modes](https://gitlab.com/agaric/agaric/wikis/view-modes) * [Wireframe](https://marvelapp.com/5c327g8/screen/36342184) ## Work Required * [x] Create view * [ ] Add "Our Work" title * [x] Customize views template * Add "is-2" class to page title * Add div around all tiles with classes "columns is-multiline" * Add div around each tile with class "column is-one-third" * [x] Package into Case Study feature

cedewey commented

2018-01-24 21:52:08 +00:00

(Migrated from gitlab.com)

changed the description

cedewey commented

2018-01-24 21:52:13 +00:00

(Migrated from gitlab.com)

added ~3378960 label

cedewey commented

2018-09-26 22:31:21 +00:00

(Migrated from gitlab.com)

changed the description

cedewey commented

2018-09-26 22:32:36 +00:00

(Migrated from gitlab.com)

changed the description

mlncn commented

2018-10-22 00:56:45 +00:00

(Migrated from gitlab.com)

@cedewey Here's feedback on the Case Study feature. Would be nice to improve it before we start using it heavily.

I think year needs to have an optional end year. Or something. Even if we define case study as one piece of a project, unfortunately that's not going to fit entirely within one calendar year most of the time.
Team allows putting multiple people per autocomplete, but also has add another item. This is a bit confusing... but it resolves to one per line later so has no effect on output or later editing. Never mind.
(Never mind this one in advance.) I think we should make Project details a paragraph type. Be able to have a closing paragraph, or a 'want a project like this?' webform after it. And honestly be able to sneak project details into other content types... although maybe this is where i need to be yanked back. OK we can't because it would be too hard to do filtering. OK i really want Drutopia to pretty radically rework the way content is built and themed. (I told you never mind.)

Content:

Is there a list of services and technologies terms that you've proposed? And even if not or as an exercise toward developing one, can you put these terms in the case study docs?

... hmm i had some useful feedback but i started this yesterday so might as well hit submit.

(Edit: there is no useful comment; ignore all this until it becomes necessary to understand my thinking, and let us hope it never comes to that.)

Oh well while i'm going wildly off topic... For a more consistent—and more powerful—site builder and themer experience, i would like to see Drutopia start to use Paragraphs for everything. This means a title paragraph by default (bonus: ability to remove or override the HTML title bar title and teaser title).
e
There's definitely some challenges here. We'd deny the ability to use paragraphs for non-Full view modes, generally. But we're already doing that, offering a summary field. Mabye the summary field would be the otly thing not turning into a paragraph. Gah but now i'm making people enter the title twice. My idea was the default title paragraph uses a token, though. The default title paragraph would also allow an image, using a token representing the image provided with the node itself (which would be used for the teaser etc.)

The reason is to put most theming into theming of paragraphs rather than having to theme things other ways. Also it allows site builders to re-order these special elements, putting a special message or even an image, video, or slideshow above the title.

Event date, event type, tags-- all in paragraphs. More control to the site builder, more consistency for themers— less work for themers also, since generally each paragraph type would be used unchanged across multiple content types. This also makes more likely more consistency for site visitors in how each element looks (albeit potentially less consistency on where they end up.)

This would sort of deprecate Display Suite. Which is my red flag that what i want here is probably not paragraphs at all, but something built on Drupal core's new layout builder.

Alternatively, just as fake fields has been a thing in Drupal, we could do fake paragraphs, so the site builder can set order on a content by content basis. But again this is my flag that i'm looking for a tool different from paragraphs, and layout builder seems to be it.

Should we be pursuing the end of content types? If you add an event paragraph / block it's treated an event, if you add a project details (see Agaric case studies) it's treated as a case study?

@cedewey Here's feedback on the Case Study feature. Would be nice to improve it before we start using it heavily. * I think year needs to have an optional end year. Or something. Even if we define case study as one piece of a project, unfortunately that's not going to fit entirely within one calendar year most of the time. * Team allows putting multiple people per autocomplete, but also has add another item. This is a bit confusing... but it resolves to one per line later so has no effect on output or later editing. Never mind. * (Never mind this one in advance.) I think we should make Project details a paragraph type. Be able to have a closing paragraph, or a 'want a project like this?' webform after it. And honestly be able to sneak project details into other content types... although maybe this is where i need to be yanked back. OK we can't because it would be too hard to do filtering. OK i really want Drutopia to pretty radically rework the way content is built and themed. (I told you never mind.) Content: * Is there a list of services and technologies terms that you've proposed? And even if not or as an exercise toward developing one, can you put these terms in the case study docs? ... hmm i had some useful feedback but i started this yesterday so might as well hit submit. (Edit: there is no useful comment; ignore all this until it becomes necessary to understand my thinking, and let us hope it never comes to that.) Oh well while i'm going wildly off topic... For a more consistent—and more powerful—site builder and themer experience, i would like to see Drutopia start to use Paragraphs for everything. This means a title paragraph by default (bonus: ability to remove or override the HTML title bar title and teaser title). e There's definitely some challenges here. We'd deny the ability to use paragraphs for non-Full view modes, generally. But we're already doing that, offering a summary field. Mabye the summary field would be the otly thing not turning into a paragraph. Gah but now i'm making people enter the title twice. My idea was the default title paragraph uses a token, though. The default title paragraph would also allow an image, using a token representing the image provided with the node itself (which would be used for the teaser etc.) The reason is to put most theming into theming of paragraphs rather than having to theme things other ways. Also it allows site builders to re-order these special elements, putting a special message or even an image, video, or slideshow above the title. Event date, event type, tags-- all in paragraphs. More control to the site builder, more consistency for themers— less work for themers also, since generally each paragraph type would be used unchanged across multiple content types. This also makes more likely more consistency for site visitors in how each element looks (albeit potentially less consistency on where they end up.) This would sort of deprecate Display Suite. Which is my red flag that what i want here is probably not paragraphs at all, but something built on Drupal core's new layout builder. Alternatively, just as fake fields has been a thing in Drupal, we could do fake paragraphs, so the site builder can set order on a content by content basis. But again this is my flag that i'm looking for a tool different from paragraphs, and layout builder seems to be it. Should we be pursuing the end of content types? If you add an event paragraph / block it's treated an event, if you add a project details (see Agaric case studies) it's treated as a case study?

cedewey commented

2018-11-01 18:31:21 +00:00

(Migrated from gitlab.com)

Date range - Right now a date field needs to include month and day. Also, end date is required. https://www.drupal.org/project/drupal/issues/2794481 We could add the Optional End Date module until it's resolved in core. There's also a Year Only module. Thoughts on this @mlncn?

I've got thoughts on your wild paragraphify everything ideas, but I'll save those for another place. ;)

1. Date range - Right now a date field needs to include month and day. Also, end date is required. https://www.drupal.org/project/drupal/issues/2794481 We could add the [Optional End Date module](https://www.drupal.org/project/optional_end_date) until it's resolved in core. There's also a [Year Only module](https://www.drupal.org/project/yearonly). Thoughts on this @mlncn? I've got thoughts on your wild paragraphify everything ideas, but I'll save those for another place. ;)

cedewey commented

2018-11-01 18:31:26 +00:00

(Migrated from gitlab.com)

assigned to @mlncn

cedewey commented

2018-11-28 19:31:54 +00:00

(Migrated from gitlab.com)

changed milestone to %7

mlncn commented

2018-12-10 23:29:52 +00:00

(Migrated from gitlab.com)

The listing section is reasonably styled. Everything else is in control of the content editor. Tossing any packaging into the Case Study feature back to you also, @cedewey

mlncn commented

2018-12-10 23:29:56 +00:00

(Migrated from gitlab.com)

assigned to @cedewey and unassigned @mlncn