Skip to content

Commit 3341cb2

Browse files
madewithkodemadewithkode
committed
Merge branch 'master' of https://github.com/madewithkode/creativecommons.github.io-source into hotfix/improve-readme
merge remote changes
2 parents ca70ffd + 07acc3f commit 3341cb2

File tree

13 files changed

+480
-21
lines changed

13 files changed

+480
-21
lines changed

‎content/blog/entries/cc-search-accessibility-week3-4/contents.lr

+98
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
title: Internationalization Continued: Handling strings in the store
2+
---
3+
categories:
4+
cc-search
5+
community
6+
gsoc
7+
open-source
8+
9+
---
10+
author: AyanChoudhary
11+
---
12+
series: gsoc-2020-ccsearch-accessibility
13+
---
14+
pub_date: 2020-06-26
15+
---
16+
body:
17+
18+
These are the second two weeks of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well.
19+
The internationalization work from the previous post is continued here and we also solve an interesting issue of translating strings from the Vuex store.
20+
21+
During this period I removed all the hardcoded strings from the static pages which include:
22+
23+
1. About Page
24+
2. Collections Page
25+
3. Search Guide Page
26+
4. Feedback Page
27+
28+
All of the above pages were then internationalized following the same procedure as detailed in the previous post.
29+
While internationalizing the homepage we ran into an interesting problem:
30+
31+
The licenses strings were being accessed from the store and those too had to be internationalized.
32+
```
33+
licenseTypes: [
34+
{ code: 'commercial', name: 'Use commercially', checked: false },
35+
{ code: 'modification', name: 'Modify or adapt', checked: false },
36+
]
37+
```
38+
The code was used to store the licenses in the store in the ordered format. The challenge was to extract the name strings from each license while keeping the changes and dependencies to a minimum.
39+
The code which we were using in the templates to load these strings was:
40+
41+
```
42+
<label
43+
class="checkbox margin-right-big"
44+
:for="licenseType.code"
45+
:key="index"
46+
>
47+
<input
48+
:id="licenseType.code"
49+
type="checkbox"
50+
:checked="licenseType.checked"
51+
name="lt"
52+
:value="licenseType.code"
53+
@input="onFilterChanged(licenseType.code)"
54+
/>
55+
</ label>
56+
```
57+
58+
So after some discussion and a great insight by @brenoferreira we came up with the idea to change to name field from the store to point to our extracted internationalization strings.
59+
This proved to be very helpful as we managed to keep changes to a minimum without using any extra dependencies.
60+
The code after implementing the changes is:
61+
62+
```
63+
licenseTypes: [
64+
{ code: 'commercial', name: 'filters.license-types.commercial', checked: false, },
65+
{ code: 'modification', name: 'filters.license-types.modification', checked: false,},
66+
]
67+
```
68+
69+
```
70+
<label
71+
class="checkbox margin-right-big"
72+
:for="licenseType.code"
73+
:key="index"
74+
>
75+
<input
76+
:id="licenseType.code"
77+
type="checkbox"
78+
:checked="licenseType.checked"
79+
name="lt"
80+
:value="licenseType.code"
81+
@input="onFilterChanged(licenseType.code)"
82+
/>
83+
{{ $t(licenseType.name) }}
84+
</label>
85+
```
86+
87+
The rest of the internationalization stuff was string extractions and template modifications to accomodate the the translated strings.
88+
And we are done with these two weeks, we be back with another post after two weeks.
89+
90+
You can track the work done for these weeks through these PRs:
91+
92+
1. [Internationalize About Page and Search Guide Page](https://github.com/creativecommons/cccatalog-frontend/pull/1024)
93+
2. [Internationalize feedback page, collections page and not found page](https://github.com/creativecommons/cccatalog-frontend/pull/1031)
94+
95+
The progress of the project can be tracked on [cc-search](https://github.com/creativecommons/cccatalog-frontend)
96+
97+
CC Search Accessiblity is my GSoC 2020 project under the guidance of [Zack Krida](https://creativecommons.org/author/zackcreativecommons-org/) and [Ari Madian](https://opensource.creativecommons.org/blog/authors/akmadian/), who is the primary mentor for this project, [Anna Tumadóttir](https://creativecommons.org/author/annacreativecommons-org/) for helping all along and engineering director [Kriti
98+
Godey](https://creativecommons.org/author/kriticreativecommons-org/), have been very supportive.

‎content/blog/entries/cc-search-accessibility-week5-6/contents.lr

+80
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
title: Internationalization continued: Modifying tests
2+
---
3+
categories:
4+
cc-search
5+
community
6+
gsoc
7+
open-source
8+
9+
---
10+
author: AyanChoudhary
11+
---
12+
series: gsoc-2020-ccsearch-accessibility
13+
---
14+
pub_date: 2020-07-10
15+
---
16+
body:
17+
18+
These are the fifth and sixth weeks of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well.
19+
This post contains yet another important aspect to be taken care of while internationalizing the Vue components, i.e. modifying tests to include the changes.
20+
21+
The components which were left are the two pages displaying the most content:
22+
1. [Browse page](https://github.com/creativecommons/cccatalog-frontend/blob/develop/src/pages/BrowsePage.vue)
23+
2. [ImageDetail page](https://github.com/creativecommons/cccatalog-frontend/blob/develop/src/pages/PhotoDetailPage.vue)
24+
25+
The above two pages too were handled similar to the remaining pages, special care had to be taken in case of ImageDetail page since there are too many components in different files.
26+
By this point we also have our json structure figured out, mostly and are ready to push the json for fetching further translations.
27+
28+
Now let's look at the modifications required in the tests. We generally use ```$t``` to access strings from the locales json, but this method/custom-component is not present in the testing vue instance, so we had to inject this method usin localVue and a custom i18n instance.
29+
30+
```
31+
const localVue = createLocalVue();
32+
localVue.use(Vuex);
33+
localVue.use(VueI18n);
34+
const messages = require('@/locales/en.json');
35+
36+
const i18n = new VueI18n({
37+
locale: 'en',
38+
fallbackLocale: 'en',
39+
messages,
40+
});
41+
```
42+
43+
Now we inject this 18n component into our vue instance and we have access to our ```$t```, but there is still one more step left.
44+
We still need to mock its functionality in the tests. So we create a mock ```$t``` instance to mock in our component. The final code is given below:
45+
46+
```
47+
const $t = (key) => i18n.messages[key];
48+
49+
options = {
50+
mocks: {
51+
$t,
52+
},
53+
};
54+
```
55+
56+
Now we are ready to render our component using these custom options with mocks for testing.
57+
58+
And *drum rolls* we have successfully completed Internationalization of the complete cc search. Below are the images for some of the completed pages:
59+
60+
![final.png](final.png)
61+
62+
![finalAbout.png](finalAbout.png)
63+
64+
![finalImageDetail.png](finalImageDetail.png)
65+
66+
The issues closed with the completion of Internationalization are:
67+
68+
1. [[META] Internationalisation (i18n) Setup](https://github.com/creativecommons/cccatalog-frontend/issues/487)
69+
2. [Set up vue-i18n infrastructure](https://github.com/creativecommons/cccatalog-frontend/issues/941)
70+
3. [Create locale messages format JSON structure](https://github.com/creativecommons/cccatalog-frontend/issues/942)
71+
4. [Allow users to change locale on the client](https://github.com/creativecommons/cccatalog-frontend/issues/943)
72+
73+
You can track the work done for these weeks through this PR:
74+
75+
1. [Localize browsepage and single-result page](https://github.com/creativecommons/cccatalog-frontend/pull/1040)
76+
77+
The progress of the project can be tracked on [cc-search](https://github.com/creativecommons/cccatalog-frontend)
78+
79+
CC Search Accessiblity is my GSoC 2020 project under the guidance of [Zack Krida](https://creativecommons.org/author/zackcreativecommons-org/) and [Ari Madian](https://opensource.creativecommons.org/blog/authors/akmadian/), who is the primary mentor for this project, [Anna Tumadóttir](https://creativecommons.org/author/annacreativecommons-org/) for helping all along and engineering director [Kriti
80+
Godey](https://creativecommons.org/author/kriticreativecommons-org/), have been very supportive.

‎content/blog/entries/cc-search-accessibility-week5-6/final.png

78.7 KB
Loading

‎content/blog/entries/cc-search-accessibility-week5-6/finalAbout.png

128 KB
Loading

‎content/blog/entries/cc-search-accessibility-week5-6/finalImageDetail.png

1.21 MB
Loading

‎content/blog/entries/cc-search-accessibility-week7-8/contents.lr

+130
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
title: CC Search, Initial Accessibility Improvements
2+
---
3+
categories:
4+
cc-search
5+
community
6+
gsoc
7+
open-source
8+
9+
---
10+
author: AyanChoudhary
11+
---
12+
series: gsoc-2020-ccsearch-accessibility
13+
---
14+
pub_date: 2020-07-25
15+
---
16+
body:
17+
18+
These are the seventh and eighth weeks of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well.
19+
This post contains details of my work done to make initial accessibility improvements to homepage and the other static pages.
20+
21+
With the internationalization work complete, our next target were the accessiblity improvements. So I decided to tackle the homepage and the static pages first.
22+
The aforementioned pages had the following accessiblity issues:
23+
24+
1. No aria-label on links
25+
2. Improper landmarks
26+
3. Improper aria-control nestings
27+
4. Some elements not being read by the screen-reader
28+
5. Color contrast Issues(to be covered later)
29+
30+
But before working I ran another set of audit tests to exactly pin-point these issues. I used [NVDA](https://www.nvaccess.org/) for running these audits.
31+
Lets go through the fixes one at a time.
32+
33+
The first issue of no aria-label was pre-dominantly found in the footer. we had some links such as:
34+
```
35+
<a
36+
href="https://www.instagram.com/creativecommons"
37+
class="social has-text-white"
38+
target="_blank"
39+
rel="noopener"
40+
>
41+
```
42+
43+
These links did not contain any aria-label and were read as **cc link**. So the aria-labels had to be added ```aria-label="instagram link"``` in this case which fixed this problem.
44+
45+
The next issue was of improper landmarks. Most of the pages had no **main** landmark and some had no **complimentary** or **region** landmarks even though they were required in those pages.
46+
These landmarks had to be added after the carefully scrutinising the pages in the audits.
47+
48+
The next issue was of improper aria-control nestings. This is interesting as it involves having some deeper understanding of the roles involved. So I will explain this in a little depth.
49+
The area where we had this issue was in feedback page. The code involved was:
50+
51+
```
52+
<ul>
53+
<li :class="tabClass(0, 'tab')">
54+
<a
55+
href="#panel0"
56+
:aria-selected="activeTab == 0"
57+
@click.prevent="setActiveTab(0)"
58+
>
59+
Help us Improve
60+
</a>
61+
</li>
62+
<li :class="tabClass(1, 'tab')">
63+
<a
64+
href="#panel1"
65+
:aria-selected="activeTab == 1"
66+
@click.prevent="setActiveTab(1)"
67+
>
68+
Report a Bug
69+
</a>
70+
</li>
71+
</ul>
72+
```
73+
The reason why this is an error is because of the ```aria-selected``` attribute can only be applied to an element having the role **tab** nested inside a **tablist** element.
74+
For reference, in the above example the ```<ul>``` should have the role **tablist** and each ```<li>``` element should have the role **tab**. And so the ```aria-selected``` attribute should be in the ```<li>``` element instead of the ```<a>``` tag.
75+
76+
The corrected code is:
77+
```
78+
<ul role="tablist">
79+
<li role="tab" :class="tabClass(0, 'tab')" :aria-selected="activeTab == 0">
80+
<a
81+
aria-label="help us improve form"
82+
href="#panel0"
83+
@click.prevent="setActiveTab(0)"
84+
>
85+
{{ $t('feedback.improve') }}
86+
</a>
87+
</li>
88+
<li role="tab" :class="tabClass(1, 'tab')" :aria-selected="activeTab == 1">
89+
<a
90+
aria-label="report a bug form"
91+
href="#panel1"
92+
@click.prevent="setActiveTab(1)"
93+
>
94+
{{ $t('feedback.bug') }}
95+
</a>
96+
</li>
97+
</ul>
98+
```
99+
100+
Another interesting finding involved the screen readers not reading particular special characters such as ```~``` and ```|```.
101+
This issue was quite pronounced in the search guide page where these symbols were used in plenty in both links as well as texts.
102+
So I had to phonetically write these out in the aria-labels of the links to make the screen reader read them out loud.
103+
The corresponding changes are:
104+
105+
```
106+
<a
107+
aria-label="dog vertical bar cat"
108+
href="https://search.creativecommons.org/search?q=dog%7Ccat"
109+
>
110+
<em>dog|cat</em>
111+
</a>
112+
```
113+
114+
After all these changes we had some increase in the accessibility scores(computed from lighthouse):
115+
116+
1. About Page: 78 -> 97 | +19
117+
2. Search-Guide Page: 76 -> 97 | +23
118+
3. Feedback Page: 75 -> 97 | +22
119+
120+
Whoosh!! That was quite a lot. We are done with these two weeks for now. Hope to see you in the next post as well.
121+
122+
You can track the work done for these weeks through these PRs:
123+
124+
1. [Accessibility](https://github.com/creativecommons/cccatalog-frontend/pull/1068)
125+
2. [Accessibility Improvements](https://github.com/creativecommons/cccatalog-frontend/pull/1072)
126+
127+
The progress of the project can be tracked on [cc-search](https://github.com/creativecommons/cccatalog-frontend)
128+
129+
CC Search Accessiblity is my GSoC 2020 project under the guidance of [Zack Krida](https://creativecommons.org/author/zackcreativecommons-org/) and [Ari Madian](https://opensource.creativecommons.org/blog/authors/akmadian/), who is the primary mentor for this project, [Anna Tumadóttir](https://creativecommons.org/author/annacreativecommons-org/) for helping all along and engineering director [Kriti
130+
Godey](https://creativecommons.org/author/kriticreativecommons-org/), have been very supportive.

‎content/blog/entries/linked-commons-autocomplete-feature/autocomplete-feat-in-action.gif

1010 KB
Loading

‎content/blog/entries/linked-commons-autocomplete-feature/contents.lr

+83
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
title: Linked Commons: Autocomplete Feature
2+
---
3+
categories:
4+
announcements
5+
cc-catalog
6+
product
7+
gsoc
8+
gsoc-2020
9+
open-source
10+
cc-dataviz
11+
---
12+
author: subhamX
13+
---
14+
series: gsoc-2020-dataviz
15+
---
16+
pub_date: 2020-07-31
17+
---
18+
19+
body:
20+
## Introduction
21+
The following blog intends to explain the very recent feature integrated to the Linked Commons. Be it the giant Google Search or any small website having a form field, everyone wishes to predict what’s on the user’s mind. For every keystroke, a nice search bar always renders some possible options the user could be looking for. The core ideology behind having this feature is — *do as much work as possible for the user!*
22+
23+
24+
25+
<div style="text-align: center; width: 100%;">
26+
<figure>
27+
<img src="autocomplete-feat-in-action.gif" alt="autocomplete-feature" style="border: 1px solid black">
28+
<figcaption style="font-weight: 500;">Autocomplete feature in action</figcaption>
29+
</figure>
30+
</div>
31+
32+
## Motivation
33+
One of the newest features integrated last month into Linked Commons is Filtering by node name. Here a user can search for his/her favourite node and explore all its neighbours. Since the list is very big, it was self-evident for us to have a text box (and not a drop-down) where the user is supposed to type the node name.
34+
35+
Some of the reasons why to have a text box or filtering by node option.
36+
- Some of the node names are very uncommon and lengthy. There is a high probability of misspelling it.
37+
- Submitting the form and getting a response of “Node doesn’t exist” isn’t a very good user flow, and we want to minimise such incidents.
38+
39+
Also, on a side note giving a search bar to the user and giving no hints is ruthless. We all need recommendations and guess what linked commons got you covered! Now for every keystroke, we load a bunch of node names which you might be looking for. ;)
40+
41+
42+
## Problem
43+
The autocomplete feature on a very basic level aims to predict the rest of a word the user is typing. A possible implementation is though the linear traversal of all the nodes in the list. It will be having a **linear time complexity**. It’s not very good and it’s very obvious to look for a faster and more efficient way. Also, even if for once we neglect the **time complexity**, looking for the best 10 nodes out of these millions on the client's machine is not at all a good idea; it will cause throttling and will result in performance drops.
44+
On the other hand, a **trie based solution** is more efficient for sure but still, we cannot do this indexing on the client machine for the same reasons stated above.
45+
So far, it is now apparent that we implement this feature on the server and also aim for at least something better than linear time complexity.
46+
47+
48+
49+
## A non-conventional solution
50+
We could have used Elastic Search, which is very powerful and has a ton of functionalities but since our needs are very small we wanted to look for other simple alternatives. Moreover, we didn't want to complicate our current architecture by adding an additional framework and libraries.
51+
52+
Taking the above points into consideration we went ahead with the following solution. We store all nodes data into an SQL dB and search for all the nodes whose domain name pattern was matching to the query string. After slicing the query set and other randomization we sent the payload to the client. To make it more robust, we are caching the results in the frontend to avoid multiple calls for the same query. It will surely reduce the load from the server and also give a faster response.
53+
54+
55+
## Results
56+
To make sure our solution works well, we performed load tests, checking that any response time does not exceed 1000 ms. We used locust which is a user load testing tool. We simulated with **1000 users** and **10 as Hatch rate**.
57+
The following test is performed on the local machine to ensure that the server location isn’t affecting the results.
58+
59+
Here are some aggregated result statistics.
60+
61+
62+
63+
| Field Name | Value |
64+
|---------------------------|---------------|
65+
| Request Count |** 23323 **|
66+
| Failure Count |** 0 **|
67+
| Median Response Time |** 360 ms **|
68+
| Average Response Time |** 586.289 ms**|
69+
| Min Response Time |** 4.03094 ms**|
70+
| Max Response Time |** 4216 ms **|
71+
| Average Content Size |** 528.667 ms**|
72+
| Requests/s |** 171.754 **|
73+
| Max Requests/s |** 214 **|
74+
| Failures/s |** 0 **|
75+
76+
Since SQLlite has a serverless design, disk io usually has a significant impact on the performance. The above results were executed on a server with HDD storage. Linked Commons server is equipped with faster disk io. It will certainly improve the performance but will be countered by the network latency and other factors like the number of nodes in the dB. So the above results to some degree resemble the actual performance.
77+
78+
79+
## Next steps
80+
In the next blog, we will be covering the long awaited data update and the new architecture.
81+
82+
## Conclusion
83+
Overall, I enjoyed working on this feature and it was a great learning experience. This feature has been successfully integrated to the development version, do check it out. Now that you have read this blog till the end, I hope that you enjoyed it. For more information please visit our [Github repo](https://github.com/creativecommons/cccatalog-dataviz/). We are looking forward to hearing from you on linked commons. Our [slack](https://creativecommons.slack.com/channels/cc-dev-cc-catalog-viz) doors are always open to you, see you there. :)

0 commit comments

Comments
 (0)