Category: Usability

When you upload an zip file into file gallery and choose "unzip zip files" the checkbox to choose a catagory has no effect. It would be nice, that all extracted files have the choosen category.

I use TikiWiki 4.2.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

Update email in mail notifications list when email replaced in user account

I did change my email in my account settings at t.o. That email was transfered to dev.t.o properly.
And my mail notifications in t.o where updated properly. __However, the mail notifications in the slave sites (from the same intertiki network) did not get updated__

I see no other mechanism for proposing corrected localization files, so I post it as a feature request to I18N. While I am still deep into the main body of translation (so far I made > 2060 corrections and additions, and custom.php has grown to 1/4 the size of language.php, 231 kbytes, I have seen that there is a smaller file, language.js, that contains some spelling errors (old German spelling which is outdated since 1996, the big official reform of German spelling) and IMHO a wrong language level (addressing the user in the second person, using imperative). And since language.js is a lot smaller, I finished this one and hereby propose it to be included in future versions. This file was writen on Tiki 18.6.
Thanks
hman

I am monitoring the dev.tw.o tracker and changed my e-mail adress to get the new tracker items to another mailbox.

Well, that didn't happen! ;)
And after re-subscribing to the tracker, now I get them twice - in both accounts.

I guess I'll have to change my mail-adress back and forth to unsubscribe..

amette update: just checked 1.9.x checkbox - more update: changing e-mail back and unsubscribing works flawlessly

Importantly, Google Maps Javascript API V3 is simply just faster than v2. Another big plus is that V3 does not need an api key. The currently used v2 api's key verification is known to have problems. It is also deprecated by google.
Read more here:
http://code.google.com/intl/fr/apis/maps/documentation/javascript/basics.html

Perhaps something for Tiki7?

Or would not it be part of Tiki6 as optional and experimental?

~~#f33:__Update!__~~

#~~#f33:Unzip Zip Files (Batch Upload) is Broken for Windows and CentOS~~
#~~#f33:Adding Multiple files one at a time, then uploading in-batch is broken __ONLY for Windows XP__ (CentOS works).~~

System Used:

1) Windows XP
XAMPP
Tiki 4.0 and 4.1 (12-15-2009)
IE 8 or Mozilla FF 3

2) CentOS 5.x
Tiki 4.0 and 4.1
IE 8

In Tiki 3.x it is possible to upload multiple files at one time to any file gallery by one of two methods:

1. Keep clicking the "Add" button and add select multiple files for uploading. Then finally click the "Upload" button.

2. Select a zip file to upload, and check the "Unzip" checkbox.

~~#f00:__In Tiki 4.0/4.1 this feature is broken.__ ~~ The resulting behavior is that the upload progress-indicator (spoked-wheel animation) runs forever, and the Apache server must be restarted before the user can continue to upload any other files after the failed attempt at multiple-uploads.

~~#f00:__For purposes of data/file migration to Tiki, this is a serious issue.__~~
I'm not much of a PHP programmer, and I suspect other Tiki users are not either...so checking out the latest code from the head of a branch is probably not a great work-around (in general).

I tried to upload a thumbnail on a tracker item for a video tutorials.
It took me 25mn and I tried half a dozens of way before succeeding.
Sorry I don’t have time to produce a better report see screenshots.

{img fileId="1425" thumb="box"}

{img fileId="1426" thumb="box"}

{img fileId="1427" thumb="box"}

https://doc.tiki.org/tiki-tracker-update_item?trackerId=20&itemId=2735

I try to upload a file (file is uploaded but not assigned and show error)
{img type="src" src="https://tiki.org/dl1996?display" thumb="box"}

I hten use the browse file button (the file was uploaded even if tiki says otherwise) and it end with a weird redirection while the tracker edit was saved.

{img type="src" src="https://tiki.org/dl1999?display" thumb="box"}

Uploading a new version of a file is not expected UX standard and display wrong information.

When uploading a new version, just after initiating the upload, the screen stay put like nothing happen. It is confusing especially for big size file as the"on hold" time will be significantly longer.
We should display a loading wheel, upload bar, whatever so the user is aware something is going on.

Once the upload is completed the page is refreshed (same display as you were in the gallery with ALL the pictures in it) and it shows only a single picture in the gallery (path/explorer is displayed). The one you just uploaded. This is misleading and look like incomplete job.

Or we should show the gallery with all the picture after the new version upload.
Or we should show a page with the single image uploading success and a link to get back to the gallery.

While these are not bugs but request, it is on a very used and popular feature.

While navigating galleries in Finder View the URL does not change. The impact of this is selecting "Edit Gallery" will result in editing the gallery identified by the out-of-date URL, and not the currently view gallery. Easily missed, resulting in editing the wrong gallery.

There is one pending issue in PluginTrackerCalendar in 12x & 13x {sign user="xavi" datetime="2014-05-27T14:46:53+00:00"}, and it was working fine in 10x, as far as I remember

Show instance where some of this issues are reproduced:
http://xavi-9794-5177.show.tikiwiki.org
u: admin
p: 12345

!! Pending still:

If you use some uppercase letter in the string of the tracker field "location" (used as a the resource field for the resource-related views), then the item is not shown through the resource views, only through the calendar type of views.

Replacing uppercase letters with lowercase in the values of those fields solves the issue as a workaround until a proper fix is found/commited

Reproduced here:

http://xavi-9794-5177.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_10

In the resource month, 3 items are shown.
In the calendar view, 5 items are shown. The extra 2 are the ones with upper case in the contents of the "location" tracker field (the field used as resource).

With "__resource month__" view:
{img fileId="783"}

With "__month__" view:
{img fileId="784"}


!!- Things Fixed already
(1) In localhost, after applying the profile Tracker_as_calendar_10x I can't get the new items to display in the resource views modes if location field is set, only in the calendar modes. Tried manually rebuilding the search index, and no way either.
http://xavi-9794-5177.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_10

In a production site of mine, many seem to display, but not some of them with specific values in the location (resource) field.

__Update April 7th, 2014__: the issue seems to be related with using some uppercase letter in the string of the tracker field "location" (used as a the resource field for the resource-related views). Replacing uppercase letters with lowercase in the values of those fields solves the issue as a workaround until a proper fix is found/commited {sign user="xavi" datetime="2014-04-08T10:54:03+00:00"}

---

(2) In a production site not all the items are displayed in the calendar (standard or resource views).
http://2014.forumsocialcatala.cat/CalendariPrograma

Move the calendar focus to April 12th, 2014, and view to resourceDay. And notice that for instance, there are no items shown for room 112, 113 and a few others, while there should be some items listed, as can be shown by filtering the items through the field "Aula (Capacitat)" and choosing "112", for instance here:
http://2014.forumsocialcatala.cat/Inscripcions

__Update April 7th, 2014__: the issue seems to be related with using some uppercase letter in the string of the tracker field "location" (used as a the resource field for the resource-related views). Replacing uppercase letters with lowercase in the values of those fields solves the issue as a workaround until a proper fix is found/commited {sign user="xavi" datetime="2014-04-08T10:54:03+00:00"}

--(3) As anonymous, when you mouse over each item you see that there is the url associated to show the item.-- E.g.:
http://xavi-9794-5177.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_10

--However, when you click on the item in the calendar, nothing happens.--

--When you do this as registered or admin, you get the popup window to edit the data. But users (anons, etc) expect to be able to at least see the full item details when clicking on the name.--

Fixed by jonnyb {sign user="xavi" datetime="2014-04-03T00:12:24+00:00"}

---
--(4) How can we choose to show in the box on the popup window, the info from some other tracker field/s of the same item? Like with maps, that you can show some other details inside the popup box.--

-- Like contents of fields: "Priority" and "Description" in: http://xavi-9794-5177.show.tikiwiki.org/tiki-admin_tracker_fields.php?trackerId=1 --

Fixed by jonnyb, when you set some fields to be shown in the popup, at the tracker edition field for popup fields {sign user="xavi" datetime="2014-04-03T00:12:24+00:00"}

---

--(5) How can we predefine some view (lets say, resource week) (so that, the link is provided for others to see that specific view).--

Fixed in r50638. {sign user="xavi" datetime="2014-04-03T00:12:24+00:00"}

---

--(6) How can we predefine some date with some params in a url, for instance? (so that, the link is provided for others to see that specific dates).--

Fixed in r50665 {sign user="xavi" datetime="2014-04-04T19:32:40+00:00"}



Xavi

{syntax type="tiki" editor="plain"}
{maketoc}
!Problem Summary
The dialog structure for uploading a file and adding a link to it in wiki page is much better than it was, thanks to the introduction of the __File__ icon in the toolbar of the wiki editor. But it is still cumbersome and error prone. Here is the process below and the usability issues that I found at various spots.

# Click on the __File__ icon
# Pick __File Gallery/Archive__ in __Type__
# Click on __Pick a file__ link
# Click on the __Upload File__
# Click on the __Browse__ button
# Click on __Upload__ button
# Browse the file system and pick the file.
# Once the file is uploaded, click on its name.
# Click on __Insert__ button

Besides the fact that this is long, there are many places where it is misleading to the user (details later). I had to try this more than a dozen times, clicking on different items, to figure out how it works. And I had help from some experts on the mailing list!

Fortunately, there are a number of very small fixes that we could implement to address those issues. See below for a discussion of the various issues and proposed fixes.

!Issue 1: __Type__ should have a reasonable default
Currently, the type is set to empty. It really should be set to either __File Gallery/Archive__ or __Attachment__ by default. Personally, I would favour __File Gallery/Archive__, because I think it's generally a bad idea to attach files to a wiki page, because it limits your ability to link to those files from other pages. But the point is: the value should default to what users most commonly use.

In some cases, the picklist only has one option in it anyways (ex: if the feature for attaching files to wiki pages is off). In those cases, then the picklist should DEFINITELY default to that single value.

^Fix: Set the __Type__ to a sensible default... I vote for _File Gallery/Archive__^

!Issue 2: __Pick a file__ link looks more like a caption than something you can click on
I never realized that I could click on it to choose the file. Someone had to actually point that out to me. Others on the mailing list have said that they need to point this out to users all the time.

^Fix: Change the link to a button^

!Issue 3: Too easy to miss the __Upload__ button
Once you click on __pick a file__ link, you are presented with the general screen for navigating and managing the File Gallery. But at this point in time, you are only intersted in uploading or choosing a file from the gallery, and seeing this complex dialog is very disorienting. In my case, I managed to miss the fac that there was an __Upload__ button on that screen, and I thought I had mad a mistake and someone pressed the wrong button or link in the previous screen. I had to go back to the previous screen several times and click on different things, and finally come back to clicking __pick a file__, and then I saw the __Upload__ button.

^Fix: Instead of having a single __Pick a file__ link (well, button, if we implement the fix to Issue 2), we should have two buttons: __Upload__ and __Choose from Server__. Or something like that (I can't think of a good workding). The __Upload__ button will take you directly to the place you currently get to after clicking on the __Upload__ button in the File Gallery screen. The __Choose from Server__ button will still take you to the __File Gallery__ navigation and management menu.^

!Issue 4: Not clear that you have to click on the file name after uploading
In Step 8, there is nothing that tells you you need to click on the file name after you uploaded it. I went through the whole process several times and it never occured to me that I had to do this until someone from the mailing list told me.

Note that there is a message to that effec that appears if you hover the mouse over the file's name. That message really should be visible at all times, not just when you hover over the file name.

^Fix 1: Make it so you don't need to click on the file name altogether.

Fix2: If that's not possible, at least put a very prominent messages saying that the user needs to click on the file name^

!Issue 5: Insert button is not clear.
In Step 9, you are back at the original pop up, and you need to click on the __Insert__ button, otherwise the link to the uploaded file does not get inserted.

Again, I had to do the process several times before realizing I had to do this. My natural tendancy was to close the popup, either by Xing it or clicking on the __Close__ button. The result is that the file does not get inserted on the page.

I think the problem is that the two buttons at the bottom say:

__Close__ __Insert__

And you naturally tend to click on the first of these two, i.e. __Close__.

^Fix: Change the order and caption of the two buttons as follows:

__Insert link__ | __Cancel__

Also, if the user clicks on the X to close the window, the link should be inserted (in other words, __Insert link__ should be the default). The reason is that it's easier to recuperate from that error (you just need to erase the link) than to recuperate from the other error (you have to start again from the beginning, to insert the link).
^

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

There are some usability issues with 3.0 (as of 3.0beta1), reproducible in the TikiLiveCD (at least from the upgrade process of a 1.9.11 to 3.0beta1)

See the bugs and issues reproduced at the video in:
http://doc.tikiwiki.org/TikiWiki+3

In summary:
There is a set of three pages which are translations of the same content: ca, es, en. You want them to be set as a translation set, and work with them. __As far as I remember__, there are some issues:
# You cannot add them to the same translation set until you select "Restrict languages", and select some (or all) languages in the restriction rule. However, by default it should list all languages while attempting to translate a page to a new language.
# You need to define your language preferences first. It would be much more usable if asked to the user, at registration time, this (and similar questions), to make his/her life easier (from the usability point of view)
# quantify page change is broken. The video cited above you'll see that the en page is added some more content. then the es page is updated to a complete translation, and marked as such. And the ca page is translated only partially, and marked as such by the user, but Tiki shows as if it was 100% similar to the en page.

HTH

{syntax type="tiki" editor="plain"}
New users are kind of lost in the process of creating a new tracker from scratch.
After they hit on save the form of the new tracker details, they are shown:
tiki-admin_trackers.php?trackerId=N

(being N the new tracker Id)

Instead, it would be much easier for tiki newbies (or even for everybody?) if they were autoomagically sent to
tiki-admin_tracker_fields.php?trackerId=N

Because it's not intuitive (from the newbie point f view) to know what to do from that interface with so many links at the moment when the new tracker has been created.
---
UPDATE: Still desirable in Tiki 12 LTS for usability for new users. {sign user="xavi" datetime="2013-11-17T09:43:36+00:00"}

usability: allow to show the form to post new comments to tracker items below the item.

Many new users to tiki sites, in barter networks (such as http://intercanvis.net ) they don't know how to contact the person who added the offer or demand just from the screen where they are seeing the item.

(for sure, captach should be shown when allowing anons to post comments to tracker items)

{syntax type="tiki" editor="plain"}
With a home page from an imported Mediawiki at tiki-index.php?page=Main+Page putting either that, or that with http://192.168.2.6/tiki-index.php?page=Main+Page or that with 192.168.2.6/tiki-index.php?page=Main+Page has no effect at all. The documentation for this feature claims that any entry here should override the Use tiki feature as homepage scroll selection, but that remains in control here, and its selection is what is shown.

So either there's a way to get this to work and the documentation's incomplete. Or the feature is broken. If the second, what would the most direct work-around be?

{syntax type="tiki" editor="plain"}
Problem: users forget their username

But they should remember their email.

Maybe this feature request is not trivial because password is encrypted with username.

But maybe it could be:

user enters email.
Tiki checks what is the username for that email

login is attempted with the username and password



Ideally, system would accept either email or login in interface (case insensitive)

{syntax type="tiki" editor="plain"}
Admin -> General -> Navigation - Use Tiki feature as homepage:

When i set this to a different feature then "Wiki" and go to http://mydomain.com
I keep getting send to wiki "HomePage".

The feature does get set in database and when you logout you get send to the set feature but not when you go to the domain name directly.

Also the drop down box never shows the feature that is last choosen when changing the set feature a few times it shows the 3th or 4th last feature that has been choosen after reloading the page it shows "Wiki" again although a different feature has been choosen and set in the database.

User cannot access their profile by clicking on their name (above logout). Admin ca.
Problem: The username itself is shown, but no clickable link is created.

Thus they cannot change their password or their email.

Showinstance:

admin / 12345 : name above login allows to access profile

Donald / 12345: name above login does NOT allow to access profile
Donald Duck / 12345: name above login does NOT allow to access profile

You can set a tracker to hold more user information.
On the tiki preferences (tiki-user_preferences.php) it will set a link "User's personal tracker information: View extra information".

With tiki in english the link will go to the user (latin-char or non-latin-char) i'm look at.
If the Tiki is set to multilingual the link is broken and will show my own (admin for example) information.

{syntax type="tiki" editor="plain"}
When you hover a user name the user avatar is always missing now

During long edit session on Doc or Dev (not only on wiki page) it happens that you have been disconnected without knowing it.

When it happen the page you were working on disappear and instead you have a message you are not authorized to use this feature or other redirection depending of your tiki setting and the feature you were in.

It leads to confusion and unless you keep cold blood, log and reload back the previous page you may loose your precious work. We have to find a better way as this is super frustrating and damage Tiki reputation.

I suggest the following on any submit, save, etc action (click on a button, etc) we have a check if action is possible and user session is still active.

If not without changing page we display a modal over the page with the login module and a cancel button so the user can relog and resume his action or get out of the page.

When you are on a page of a wiki structure, you can click on the print icon, but you will only print that single page.

The icon and option to "__print this page and all the subpages__" (= in the the sub-structure) right from there (without going through all the clicks at "Wiki > multiprint > select structure > print") would be very welcome, since the base feature to rpint the full structure exists.

From the home of the structure, it would print the full structure (as it can be done with one click from a structure within a Workspace through ((doc:AulaWiki)) mod, or through many clicks as usual, as explained above).

If the user is on a subpage of the structure, that button would print that page and all subpages from the same structure.

Does it make sense?