Search, sort and filter

[robertocarroll]

V important template. This needs a lot of work and testing. It is the heart of the site for many users.

See https://github.com/robertocarroll/icc-alpha/issues/60 for discussions around this template. User will come to this template either:

1. Directly to see all of a certain content type, e.g. all press releases, all court records, then filter selection to match desired criteria.
2. From a "more" link, e.g. on Lubanga case shows latest three court records and more link will take to this layout pre-filtered by Lubanga case.

[robertocarroll]

Template used for: 2.9 Court records (see #41) 3.1 Press releases 3.2 Media advisories 3.3 Statements 3.4 Announcements 3.5 Op-eds and articles 3.6 Weekly Updates 4.4 Reports 4.5 Publications

[simmigaba]

Additional requirement for "Search, Sort and Filter" page for Court Records: -- fetch the data from new centralized document libraries for CRM module -- display the latest version of Court Record (i.e. latest Corrigenda or latest Redaction or Original document if published after Redaction) in case multiple versions of same Court Record exists -- Always show the language of the current site if Court Record in that language is available. If not show the original language

New filtering rule: Display all court records from a specific Situation/Case where sequence number is between specific ranges.

[robertocarroll]

Adding search, sort, filter design composition.

[robertocarroll]

Adding feedback sent to KS earlier in the week:

1. I really like the use of colour for the metadata on the court record.
2. What do you think about the accordion/radio buttons vs a set of dropdowns? Dropdowns show the state of the filter at a glance, but the top area captures that as well. Radio buttons allow the user to see all options in that area at a glance when in that option. Do we need to test on some users and see which is better or do you have strong feelings about the correct approach? Also I think it might be worth showing the smaller screen version because this is driving this approach.
3. I really like the top area where the filter state is shown and updates in response to the user action. Would it be worth showing how it would work with more than one selection? Could that build up into a readable sentence, e.g. 26 [Document type] in [language] for [case/situation] by [source] from [phase] x . Will there be a single cross which will act like a clear all / reset filter?
4. Another issue which I didn’t mention in our earlier conversations is about the relationship between Situation and case. Case is a child of situation, e.g. Kenya > Ruto and Sang case. You can’t be on Ruto and Sang without being on Kenya, so when you click on Ruto and Sang, Kenya will automatically be selected, but situation > case is not an isolated case. There’s lots of points where one of the filters affects the possibilities of another filter. e.g. Document type and source - only some document types come from some sources, e.g. Phase and document type and source - only some documents from some sources occur at a particular phase.
5. One of the use cases for date is a range - Does it need two boxes - a published after date and a published before date?
6. The emphasis on the case over the court record title seems a bit too stark. The users of this area will most likely be looking for something in particular, i.e. I think the court record title needs more prominence than the case.
7. Will a user be able to subscribe either by email or RSS to a particular point of their faceted search? e.g. Decisions in English for Ntaganda Case by Trial Chamber. If so, we need to add the RSS and email icons and links perhaps below the filter state area at the top?

[kyleschaeffer]

1. Thanks, we like it too!
2. Personally I feel the radio buttons are a bit more touch-friendly. I'm not sure how well a drop-down would work inside an accordion, because we would have two "drop" animations nested within each other (click on the accordion to "drop" the panel, and then click on the drop-down menu to "drop" the menu). In my opinion, that would be somewhat confusing, but we're open to suggestions.
3. I agree, the sentence structure would work great here. I'm not sure it's necessary to show this in the design composition, but we'll be sure to build this into our template when we develop it for Simmi.
4. I understand the concern here. Honestly, this is more of a technical thing that Simmi will have to consider. The options that appear under the "case" panel (and all panels, for that matter) will need to be filtered based on what is selected elsewhere on this page. I think our design demonstrates the overall pattern of the interface here, but we'll definitely want to consider the filtering during testing/development.
5. A date range is a great idea. I think the current design could handle this. The button (with the calendar icon) could open a small panel that contains two fields, one for start date and one for end date (both optional). Users, when focusing on the field, could be presented with a calendar picker (i.e. http://jqueryui.com/datepicker/) to choose a date for each field. We'll probably want to fall back to a generic date control for mobile users, which works similarly across platforms.
6. Good point, we'll tweak this in the design to make the emphasis less jarring.
7. Great idea, we'll add this to the design.

[simmigaba]

1. Agreed.
2. I agree radio buttons are a bit more touch-friendly but at the moment we already have 30 different values for Situation and Cases, 39 different values for Source, 50 different values for document type, etc. Generating radio buttons for all these and asking user to select may not be that friendly. Infact we can have a better responsive web design using dropdown/ scrollbars in dropwdown/ vertical and horizontal drop downs as per layout etc. Drop downs also gives us flexibility to do multi select which may be a requirement in future e.g. select multiple Cases in a Situation or select multiple document type and source values etc. And From programming point of view, having drop downs is easy for me. As the value list in drop down is not static but is populated dynamically from Meta data Term Store which will change in future. So adding a new value to a dropdown UI control dynamically is more clean to manage rather then generating list of Radio button controls dynamically based on set of values. Also From underlying event model, managing and triggering a event on dropdown value change is more easy to implement as compared to event trigger on change in radio box value selection (I can provide more technical details if require). In addition, when User Clicks on "More" button in Court Records web part on Lubanga Case Page and comes to Index Page then the values in Situation and Case dropwdown are selected automatically. Showing same behavior by means of setting appropriate radio button value and showing expanded view of filters by default is more tricky. If there is no strong demand by users, I will stick to original approach of having drop downs.
3. Again if we stick to our approach of drop downs, then at any given time user will always know what filters are selected by looking at left side panel as drop downs show selected value. Having these additional filter labels on top of page and building whole new event model based on actions taken on these labels is duplicate effort as then Left hand side filters and filter labels on top of page have to be in synch and we are then providing two different styles of filtering on same page. Is it really required?
4. There is no relationship defined in ICC Court Records Management System between Document Type or Source or Phase of Case in which a specific document type can be published by a specific source. Even if we try to build such a relationship it will not be hierarchical but Many to Many value mappings between these fields and can't be managed in a Term store. Document Type, Phase and Source are managed as separate list of meta data values at "same level of hierarchy" in the term store. We only have hierarchy defined for Situation and Cases where we have Situation as first level and Cases in that Situation as 2nd level. So only possibility to include such logic is for Situation and Cases list but this requirement is not yet planned in current Sprint 2. At the moment selecting a value in any filter doesn't dynamically change the list of available/ applicable values in other filters. So if user selects a combination which is not valid e.g. specific Situation value and Case value from another Situation, then no Court Records will be displayed. If required, Such logic can be developed for Situation and Cases list in future sprint.
5. Yes we need start and end date. And Yes we can implement the logic for same.
6. Agreed.
7. Agreed.

Some other points missing per new CRM Module design: -- There will be a new filter for Sequence Number Range i.e filter based on Start and End Sequence Number. -- The language value "English" or "French" for each court record won't be displayed. By default we will select the latest Court record available in site language. -- There will be a label like "Including Annexes" for each Court record shown on Index webpart. This label value is generated dynamically based on certain rules which I am currently clarifying with Armin.

Another question -- by when we can have the working template for the new design so that I can incorporate the UI changes in the Court Records Index WebPart. Please note that I will be finishing all the dev work for new CRM Module (i.e. Sprint 2) by later today. Therefore I will be implementing any further UI changes as tasks for Sprint 3 starting from next week provided I have HTML/CSS etc available for new UI.

Thanks.

[robertocarroll]

So:

.2. It sounds like dropdowns are the way forward. Kyle: do you agree and do you have some ideas about making them a bit better looking than at the moment?

.3. I still like the idea of building up the filter state at the top - it provides useful info alongside the number of records and gives the user a idea of the current state at a glance. Perhaps just a single cross to clear all would be best (I think I suggested this before, but suggesting it again in the new context) because it would act as CLEAR ALL - a useful bit of functionality which isn't easy to achieve with multiple filters.

.4. OK. I think I was making this more complicated than necessary. If there's no results, it will just say "no results".

[simmigaba]

1. Thanks Rob. Yes I think we can use Kyle's expertise to make left side dropdown panel look visually appealing. And we can always improve it further (make it more user friendly and responsive) after testing it on different clients - mobile, tablet, PC etc.

2 OK. Then I will look into implementing the filters state at the top. Clear All will also be a good functionality for users.

1. Ok. Thanks.

[kyleschaeffer]

Agreed, I think if there are 30 choices in some instances, drop-downs will definitely be the best option. We'll play around with this and figure out the best presentation of drop-downs so that these are very user-friendly.

[simmigaba]

The coding changes for this Web Part are done as per new CRM design requirements. Features implemented are:

1. Based on Filters selected or control redirected from other site page (i.e. Situation or Case value etc), Fetch latest Court Records across multiple Situation and Cases from centralized Court Records library ordered by Publishing Date (Descending).
2. Fetch only latest Court records i.e. latest Corrigenda for a given Sequence number or latest Redaction (or Original) for a given Sequence number
3. Display the latest Court Record in the site language i.e. if latest Corrigenda is available in both English and French then display the English record if site language is English otherwise display French
4. If latest Court Record is only available in other language then display the same i.e. if latest Corrigenda is only available in French then display the French record if site language is English
5. Display all the latest Court records from Parent Case if the Case has Parent Case (i.e. scenario of Case Split or Case Name change). To display Court records from Parent case, again Points 1-4 above are applicable.
6. Display all the latest Court records from Child Cases if the Case is created after Merging other Cases (i.e. scenario of Case A and Case B Merged into Case C). To display Court records from Child cases, again Points 1-4 above are applicable.

Please refer to snapshot below for further details:

The main changes left to do for this webpart are from UI perspective. Mainly:

1. Calendar for Start and End date
2. UI changes to display drop-downs, Search button and Textboxes
3. Use of color for the metadata on the Court Record
4. Filter Labels on top of the page/ Clear All
5. Overall UI/ look and feel of this webpart

Awaiting design artifacts from Kyle to implement the UI changes for this webpart. Hence moving this task to Sprint 3 so that it can be done this week.

[simmigaba]

Kyle: "Hi, Simmi. We've completed our template development for the Court Records page. You can view the HTML templates here:sharepoint13vm.cloudapp.net/sites/icc/Pages/Court-Records1205-3171.aspx"

All, Based on the HTML version provided by Kyle, I have now modified the UI for CR Search, Filter and Index Page WebPart. Please view the latest page at: http://sharepoint13vm.cloudapp.net/sites/icc/court-records You can play around with different filters to see how the Court Records display list is changed based on filter values. Please note that the new requirement of adding "filter state at top" will take much more time so I have parked this item for later stage of the project. Reason being that we already have 12 different filter types on left so there are too many combinations possible to generate the sentence for "filter state at top" in a generic and meaningful way.

Kyle, In addition I want to request few minor enhancements for this Page: -- If you visit the above link, then we have added 2 new Text Box Filters -- "Start Seq No" and "End Seq No". Can you please provide new icons for these fields? -- Icon for Search field is missing. -- The icons for Start Date and End Date are blank.

Thanks.

[kyleschaeffer]

Hi, Simmi. It looks great, thanks. I'll pick three icons for these fields and let you know the HTML changes that will need to be made for them to appear in the sidebar.

[kyleschaeffer]

Hi, Simmi. You can see our changes to the HTML here. Copy our format and the icons should be fixed. Thanks!

http://sharepoint13vm.cloudapp.net/sites/icc/Pages/Court-Records1205-3171.aspx

[robertocarroll]

Small but perhaps important suggestion for this layout: increase the font size on the title and make it bold. It gets lost at the moment. What do you think?

Current

Suggested