31
daddystu
cursor direct into login field
  • 2005/2/2 5:16

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


How does one set things so that the cursor will be in the login field waiting, blinking for users to simply type in their name??

i.e. send the browser to the login page and type, no mouse clicking, no tabbing??

lazily,
daddystu



32
daddystu
Re: Action Item #4 - rolling the ball
  • 2005/2/2 4:58

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


hey jorge, thanks for the input now and continued

I too like the simplisity of the spreadsheet.
Here is a quick first draft.

jenny, I agree 100% if not more that we need this to be presented in a way that others can contribute to. Please don't misunderstand me, I just think that first of all we need to get our direction right and a few of us can generally do that better than many.

Have a look over this excel sheet and post here, thanks.

Stu



33
daddystu
Re: Action Item #4 - rolling the ball
  • 2005/2/1 12:03

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


no worries, when you can.


I'll see if I can dig up anything on the XOOPS glossary...

I have used the dictionary module, yes, but apparently it has (had) a security vulnerability that I don't really understand. That was v0.9 though, still I digress

Let's bang through an initial list on the admin control panel section ourselves and see where we get to if that's OK with you.

I thought that might be better at first, then when we have the basic list, offer it up to some more people
for opinions, then maybe putting into such a module might be good for continual development. I could probably setup a temp server we could use...I'll have a look for the new one.

Catchyer later



34
daddystu
Action Item #4 - rolling the ball
  • 2005/2/1 1:04

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Here are some ideas to get the ball rolling.

I have taken jensclas's offer of help and we will use this board to post updates.
Dave if you caould please add jensclas to the team members, that would be great, thanks.

Here is a starting outline...

I am not used to working in cyberspace so am actually wondering what the best way to collaborate would be..posting here is a good base but if there are screenshots and/or looooong messages?? And versioning of course. Any help on that would be appreicated.

Cheers


**********
XOOPS Quality Assurance team
Date:January 31, 2005

TASK:Action Item#4
Define which areas require 'standard' terms. UI buttons - 'Submit' c.f. 'Send' for example. Next would be translation of these.

Members: daddystu, Japan, jensclas, Australia

**************
TERMS for this ActionItem itself

ADMIN CONTROL PANEL>the administration area where all modules can be administered, the XOOPS admin area

MODULE ICON > the icon/graphic, usually yellow, which represents the module in the admin control panel area

MODULE ADMIN PAGE> each module has one or more admin pages. Access to these pages is by clicking on the module icon in the admin control panel or by clicking on one of the menu items when mousing over one of these module icons.

XOOPS USER INTERFACE>any non-admin area of XOOPS and/or its modules.

*********
ACTION ITEM ROADMAP
1:Pinpoint the elements.
2:Create a list of English language that could be used for these elements.
3:Test and remake the list by comparison with several modules.
4:Translate the list.

*********Start with 1***

1.Pinpoint the elements that are generic to any XOOPS module (or very common - shared among many modules).
1.1:XOOPS CORE TERMINOLOGY
1.2:ADMINISTRATION USER INTERFACE (ADMIN UI)
1.3:USER INTERFACE (UI)

**********************
1.1:XOOPS CORE TERMINOLOGY
A module developer may provide instructions and/or the functionality of their module may refer to core parts of Xoops. The terms used must match that of the XOOPS devs.
Example, the administration Control Panel. Blocks...etc.
There should be a glossary in the XOOPS docs for this, so we should not have to do anything here, it is included for completeness.??? DO WE NEED THIS?

1.2:ADMINISTRATION USER INTERFACE (ADMIN UI)
1.2.1 control panel>> the names of the different module admin pages.

Looking at some modules, grabbing the names of 'generic' terms, we can start to make a list such as...
Preferences
Permissions (Group's permissions|Permissions|Submit/Approve Permissions|Permission Settings)
Config
Settings


1.2.2 module admin pages >> buttons, labels found on individual pages...
commiting button label
Go!
Submit
Send

jenny - this is where I think we should start, how about we both look over some modules and produce a list each, compare them and then check for the generic terms??



35
daddystu
Re: Action List
  • 2005/1/27 21:16

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Quote:

Dave_L wrote:
Sorry, I've been meaning to update this topic.

About the "test module", I'm not sure what that means. If you're talking about action item #1, I figured the person (or persons) doing that action item would choose the module.


I didn't assume that, sorry. How about those doing Action #1 submit their preferred choice of module...just in case.
Also then everyone does indeed know
1.that Action #1 has started
2.which module is being worked on.



36
daddystu
Re: Action List
  • 2005/1/24 11:21

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Quote:

jorgebarrero wrote:
I suggest to use the most simple module for this purpouse.
The contact module (the one that comes with xoops).

The reason is simple. It is simple enough to document it, to review and to train people on how to use smoke tests and so on.

Even we can modify what ever, do some enhacements on the module just to make it fit the standard, and then on use it as a reference.

Probably we have to add some fetures that include the usage of the data base (for example to choose from a list of posible contacts).

A very simple module would be ease to explain to newbies, and will not be a distraction on the core process.

Jorge

SImple is definitely good, for all the reasons outlined here
BUT
I am thinking that a 3rd party rather than a core module would be easier.
You don't have to upload and unpack a core module (is that the right term? = any module that comes with the XOOPS package?).

Since I am not a coder, I have no idea but it certainly is possible that a core module has certain features that make it core??

Simple is good, familiarity can help there.
I would go for SmartFAQ.

How about a poll>>>Dave?



37
daddystu
Re: Action List
  • 2005/1/18 15:14

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Action Item #5: Decide on a test module

This should be fairly easy...



38
daddystu
Re: Action List
  • 2005/1/18 15:11

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Quote:

Dave_L wrote:
I haven't gotten any PMs though, except for Marco, who has volunteered for item #1.


Gyah!
Sorry guys! So where are we all? hellooooo.

I can look at Action #2..



39
daddystu
Re: Action List - terminology
  • 2005/1/18 15:06

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Action Item #4: List of terminology

Define which areas require 'standard' terms. UI buttons - 'Submit' c.f. 'Send' for example. Next would be translation of these.



40
daddystu
Re: Action List
  • 2005/1/18 14:51

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


I think Dave asked for PMs so I am hoping that people did which is why it might be quiet here??





TopTop
« 1 2 3 (4) 5 6 7 ... 9 »



Login

Who's Online

275 user(s) are online (179 user(s) are browsing Support Forums)


Members: 0


Guests: 275


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits