I'm a noob too, but I'll try and give a bit of an answer.

To know what the server must do and what the client must do depends on how secure you want your game to be. If you let the client compute a lot of things and make the server become just a multiplexer, then somebody can hack your client and send false information and the server will probably not notice.
So, generally, the server has to at least double check information sent by the clients. If you're going for something simple, the clients can just send inputs to the server which will then process them and make a character move or whatever.

For your problem : make your character move only. If you want him in the middle of the screen, just make the client move his view port accordingly to his character.

The way I'd do it is to use an inverse translation before drawing but it's probably not the right thing to do. Sorry to not be able to help you more.

What I do is have all the game logic in the server and it just sends the position of all moving objects.

the problem I get if I just send positions to the server every time I  move is:

Because of the camera thing I mentioned in my first post, I move each object one step in the opposite direction of that I am moving - I would also be moving other characters with this now would I not? (I know I could just ignore "instanceof Character" when I move my objects but then the character might end up getting stuck on in a wall on my screen). So basically my idea is to have all the logic on the server and all the actual work run there (it'd be a small game, perhaps at maximum 10 players, would this be ok?) but how would I then fix my camera problem?

I started to work with slick2d yesterday and I find it very interesting - the 'tile maps' might be something for me? Does it have some inbuilt feature for stuff like this?

I feel really stupid not being able to figure out how to solve this myself but I've just tried and failed in so many ways I can't remember which ways there's still to try:(

wow I thought I made that clear, sorry! :/
With camera I mean the frame that follows my character. Say if my character is positioned in the middle of a 800x600 frame then I consider that frame to be my camera. If I move 100pixels to the right, I want the camera to follow and update with my new surroundings.

I hope you understand now.

Basically you just have a scrolling map? I don't see why this would affect anything for client/server work. If it does, there must be something really wrong in your design.

Ok now, how to make a good client/server where the server is the decision maker (validate every move from the client) and the client doesn't have any lag? Here is a solution :

You will need to run a simulation of your code on the clients and on the server. Yeah you can't save this, the server need to run the exact same logic game update code as your client.
On your client you need to have 2 world. One world that is up to date (current time) and another one that lag behind. The world that lag behind is for comparison. You will compare this world with the world that the server will send to you from time to time to see if your client is still sync with the world of the server. If it's not, you will take the world from the server, send it to the client, update it to the current time and continue your simulation. To do so, you need to keep track of every move that you did and every move that the server told you the other players did.

The world that will be display on the client screen is the up to date world. In this world, when the player make a move (like move forward) the client automatically move forward so there is no lag. Then this event reach the server and the process of validation (as mentioned above start). If everything is perfect, there will be no modification to the client if there is a problem the simulation will be rerun from the point were the problem occurs. But most of the time, there shouldn't be a problem.

That way you got a client with no lag and it will be synchronize with the server.

Ok, that's simple to explain like that but it requires a couple of work and things need be done right.

One of the thing that you will see is that the server doesn't require to have the drawing code so you can remove it to reduce the overhead of running the same simulation on the server.

Another very important thing is that you need to have a fix deltaTime for your update method. If you have a random deltaTime, you can't synchronize the client and the server with this method. So get a good gameloop. With your fix deltaTime you can assigned each input from the player to a specific update. So if on the client side the player press to move forward on update 213, on the server this client need to be move forward on update 213. You always need to update on the same update number. That bring another problem, the update number on the client and the server need to be roughly the same hence the need of an synchronized clock between the client and the server.

So yeah it's a lot of work. If you don't need to have perfect simulation on the client then just make the server decide everything and send message to the client for when to move or do a specific action. The simulation won't be perfect and you will feel the lag a bit but it's easier.

@Gudradain
Thank you very much for your answer. Indeed I have understood that "basically I should just have a scrolling map". But the problem is, still, that I do not know how to implement this in a good way:/

I think I managed to solve this, I can't believe I did not realize I could draw stuff on a certain spot even without changing their actual positions.. Works now anyway! Thanks!:)