reasonably simple way to enter issues needed

Next topic

Author	Message
zurgutt -	Monday 14 December 2009 1:19:40 pm It takes too much effort to report site issues in the common ez tracker. Navigating there, finding the right place (not intuitive!) and figuring out right options to check etc takes way too long, so most people probably dont bother. There should be a link on front page to VERY simple form directly on community site, to report the issues. You would get much, much more good reports. Best approach is 2 way process. First "Enter short desription of issue here" form, which then does search and offers list of results. "Is your issue among the results?" "If so, mark it to vote, if not, click here to save new issue. Certified eZ developer looking for projects. zurgutt at gg.ee
Gaetano Giunta	Tuesday 15 December 2009 12:55:35 am While I agree on making a simpler interface, the post-first-search-later approach does not work very well imho. 1 - I can just ignore the 'found another similar issue' warning if I'm in a hurry anyway, and most people will do that, even if they have plenty of time. Forcing them to search first actually makes them think more about their own bug/request, so that the formulation is clearer in the end. 2 - if related issues presented are few / presented with a short text, it is hard to tell whether they really relate. If there are to many / with long texts, it is hard to read them all 3 - current implementation of the concept that springs to my mind: pecl/pear issue tracker. 99% of the "similar issues" presented are absolutely unrelated and just a waste of time. The important 1% is lost in the sea of related_issues text Principal Consultant International Business Member of the Community Project Board
zurgutt -	Friday 25 December 2009 10:11:21 am I was describing a search first, post later, if no similar found approach. Sure, some people may ignore the search result but importance of looking through them can be politely stressed on the result page. Anyhow, it is better than alternative, with no search. Forced search was only one important aspect tho, my main point was doing away with useless complexity of current tracker. Certified eZ developer looking for projects. zurgutt at gg.ee

Author

Message

Monday 14 December 2009 1:19:40 pm

It takes too much effort to report site issues in the common ez tracker. Navigating there, finding the right place (not intuitive!) and figuring out right options to check etc takes way too long, so most people probably dont bother.

There should be a link on front page to VERY simple form directly on community site, to report the issues. You would get much, much more good reports.

Best approach is 2 way process. First "Enter short desription of issue here" form, which then does search and offers list of results. "Is your issue among the results?" "If so, mark it to vote, if not, click here to save new issue.

Certified eZ developer looking for projects.
zurgutt at gg.ee

Gaetano Giunta

Tuesday 15 December 2009 12:55:35 am

While I agree on making a simpler interface, the post-first-search-later approach does not work very well imho.

1 - I can just ignore the 'found another similar issue' warning if I'm in a hurry anyway, and most people will do that, even if they have plenty of time. Forcing them to search first actually makes them think more about their own bug/request, so that the formulation is clearer in the end.

2 - if related issues presented are few / presented with a short text, it is hard to tell whether they really relate. If there are to many / with long texts, it is hard to read them all

3 - current implementation of the concept that springs to my mind: pecl/pear issue tracker. 99% of the "similar issues" presented are absolutely unrelated and just a waste of time. The important 1% is lost in the sea of related_issues text

Principal Consultant International Business
Member of the Community Project Board

zurgutt -

Friday 25 December 2009 10:11:21 am

I was describing a search first, post later, if no similar found approach. Sure, some people may ignore the search result but importance of looking through them can be politely stressed on the result page. Anyhow, it is better than alternative, with no search.

Forced search was only one important aspect tho, my main point was doing away with useless complexity of current tracker.

Certified eZ developer looking for projects.
zurgutt at gg.ee

eZ debug

Timing:	Jan 29 2025 14:41:42
Script start
Timing:	Jan 29 2025 14:41:42
Module start 'layout'
Timing:	Jan 29 2025 14:41:42
Module start 'content'
Timing:	Jan 29 2025 14:41:42
Module end 'content'
Timing:	Jan 29 2025 14:41:42
Script end

Main resources:

Total runtime	0.0147 sec
Peak memory usage	2,048.0000 KB
Database Queries	3

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0061	588.5859	151.2422
Module start 'layout'	0.0061	0.0034	739.8281	36.6953
Module start 'content'	0.0094	0.0041	776.5234	94.2188
Module end 'content'	0.0135	0.0012	870.7422	33.9922
Script end	0.0147		904.7344

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0023	15.4926	14	0.0002
Check MTime	0.0010	7.0006	14	0.0001
Mysql Total
Database connection	0.0008	5.6500	1	0.0008
Mysqli_queries	0.0036	24.5336	3	0.0012
Looping result	0.0000	0.1700	1	0.0000
Template Total	0.0009	6.0	1	0.0009
Template load	0.0007	4.7075	1	0.0007
Template processing	0.0002	1.2631	1	0.0002
Override
Cache load	0.0005	3.2129	1	0.0005
General
dbfile	0.0003	1.8412	8	0.0000
String conversion	0.0000	0.0615	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded	Edit	Override
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 1 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs